Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
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
=> 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.