Christian Limpach wrote:
> Quoting Stephan Uphoff <ups@stups.com>:
> 
> > > The cpu-queue wins over the 
> > > global queue if both have lwp's at the same priority.
> > This can theoretically cause starvation of LWPs on the global queue.
> 
> won't these get rescheduled at a higher priority eventually

Yes.
However I can create strange scenarios where there would always be 
SA LWPs around with the best priority. (Even without resorting to nice)
LWPs in the global queue would never get a chance.
This is why I used the "theoretically" qualifier ;-)

> It would be possible to do without the global queue and always 
> pick a cpu in setrunqueue.  I tried to keep the overhead as low as 
> possible, especially in cpu_switch.

A working scheduler balancing per CPU run queues while trying to
improve locality would be highly desirable.
( CPU affinity masks would also be great ) 

> > This means that your patch inherits the UP problems of the current
> > SA code. (Generally triggered by low memory conditions)
> 
> yes.  I assume these have to get fixed anyway!?  Isn't it an advantage if 
> the UP and SMP case have (only) the same problems?  Unless there's 
> something really flawed with my approach, is there?

Any fix for the low memory UP problems will probably automatically
fix the SMP problems since they are closely related.
(At least this is how it worked out with my patch)
My feeling is that you started from the wrong end of the problem.


	Stephan