Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: YAMAMOTO Takashi <>
From: Jason Thorpe <>
List: tech-kern
Date: 09/21/2006 09:53:12
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.

-- thorpej