Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Matt Thomas <matt@3am-software.com>
List: tech-kern
Date: 09/20/2006 11:47:02
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.