YAMAMOTO Takashi wrote:
>> 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?)

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.

> 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.

It'd be nice but I don't don't see how to do that.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.