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