On Tue, Mar 06, 2007 at 07:52:51AM -0800, jonathan@dsg.stanford.edu wrote:
 
> In message <20070306144026.74DC1233C4C@mail.linija.org>,
> "Mindaugas R." writes:
> 
> >jonathan@dsg.stanford.edu wrote:
> >> If there's no global run queue at all, how do you rebalance across
> >> CPUs? 
> >It depends on scheduler implementation. There would be a sched_migrate() in
> >the API, provided for "outside", but in general - all balancing would be done
> >internally i.e. dispatcher would not know anything about it, thought.
> 
> I don't follow how this would work.  Can you explain how the case of,
> say, 4 CPUs, 5 longterm (infinite) always-runnable CPU-bound tasks,
> plus a few I/O bound threads, would work so as to give fairness across
> the 5 CPU-bound processes/threads?  I'm not seeing how you would know
> which processes to move, or where, or for how long, without some
> global state; or (alternatively) without grabbing locks on other CPU's
> internal scheduler state.

Yes, foreign CPU state must be inspected. The rules for migration are
specific to the scheduler. The idea we are going with is to seperate
this out so that it's possible to experiment with different strategies.

Regularly locking up all other CPUs is a non-starter, though. The system
needs to be smarter than that.

> Which sounds like it could lead to deadlocks.

Yeah, right.

Andrew