Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: None <>
From: YAMAMOTO Takashi <>
List: tech-kern
Date: 09/21/2006 02:46:04
> I'd rather cpu_idle() do the looping.  Shouldn't cpu_idle() also
> unset curlwp?  If so, I'm not sure I like returning back to the
> scheduler on a idle stack with no curlwp.  Instead cpu_idle() should
> I think we should add a member to cpu_info which indicates cpu_idle
> should continue to loop.  When nonzero, it represents that there may
> be a new lwp to be run.
> void cpu_idle(struct lwp (*getnext)()) __attribute__((__noreturn__));
> cpu_idle would call back its first argument to get the next lwp to
> run.  When it returns new lwp, it will have already been removed
> from the runqueue.
> cpu_switch should die; either we call cpu_switchto or cpu_idle.

what is the getnext callback for?
unlike cpu_switch(), cpu_idle() doesn't need to know the next lwp to run.
checking a member in cpu_info should be enough.
(btw, why noreturn?)

i think what gmcgarry did on his branch is nearly the best, except:
	- cpu_idle shouldn't know about sched_whichqs. (as you say)
	- it's better to make cpu_idle and maybe cpu_switchto be called
	  without sched_lock held.