Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: Matt Thomas <>
From: Daniel Sieger <dsieger@TechFak.Uni-Bielefeld.DE>
List: tech-kern
Date: 09/19/2006 21:15:14
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Matt,

On Tue, Sep 19, 2006 at 07:53:30AM -0700, Matt Thomas wrote:
> kern_synch.c should not have a cpu_idle() implementation since that's
> MD code.  You don't seem to deal with __HAVE_BIGENDIAN_BITOPS.

Mmh, forgive me my blindness, but I don't really see were cpu_idle()
uses MD code. Can you give me a hint what I'm missing?

> I'd rather cpu_idle() do the looping.

Agreed. IIRC, gmcgarry did something similar in his chooseproc()
function. I'll change that.

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

Yes, you are right. cpu_switch() does the same.

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

Sounds reasonable to me.

> cpu_switch should die; either we call cpu_switchto or cpu_idle.

Yes, indeed.

Ok, I'll try to implement your suggestions. Thanks a lot for your


Daniel Sieger  =20
Faculty of Technology
Bielefeld University

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.4 (SunOS)