Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: Jason Thorpe <thorpej@shagadelic.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 09/21/2006 10:01:06
Jason Thorpe wrote:
> I'm sorry I haven't had a lot of time to chime in on this thread...
> but here goes.
>
> On Sep 20, 2006, at 8:05 PM, YAMAMOTO Takashi wrote:
>
>>> Because I don't cpu_idle to return to the scheduler code with
>>> curlwp == NULL.  I think the only place in the kernel that curlwp
>>> can be NULL is in cpu_idle.  the noreturn was a brain fart.
>>
>> maybe it's better to introduce idle threads, so that
>> cpu_idle can be independent from any real threads?
>
> Here is generally what I would like to see:
>
> => per-CPU idle LWPs (associated with proc0).
>
> => A new reschedule() routine chooses the next LWP to run.  If there
> are no LWPs on run queues, the CPU's idle LWP is chosen.  The selected
> LWP is switched to using cpu_switchto().  The main benefit here is
> that idle is no longer special-cased (besides -- MP systems need to
> have idle PCBs anyway, so might as well make them full-fledged
> scheduled entities).
>
> => idle() (written in C, in MI code) implements idle policy.  This is
> where we can check for new processes to run, zero free pages, etc.  If
> there is no "idle time" work to do, then cpu_idle() is called.
>
> => cpu_idle() does NOT loop!  cpu_idle() simply does the truly MD
> things that idle would do, e.g. call the HLT instruction or do other
> idle-time power saving, etc.  Once that special instruction has
> finished executing, we know that something has happened (i.e. an
> interrupt that may have caused an LWP to become runnable), so we
> return back to idle(), which loops around again (thus checking for
> runnable LWPs... lather, rinse, repeat).
>
> => Note that cpu_idle() could be implemented as a macro that expands
> to inline assembly, or expands to nothing, or...
>
>
> The point is to keep all of the complexity out of the MD code.

Yes, yes yes!  I agree with all of it!  So when can we do it? :-)

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191