Subject: Re: Scheduler API changes for yamt-idlelwp
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Daniel Sieger <dsieger@TechFak.Uni-Bielefeld.DE>
Date: 02/19/2007 13:14:56
On Sun, Feb 18, 2007 at 07:06:03PM +0900, YAMAMOTO Takashi wrote:
> if you think any schedulers need it for now, why bother to move it
> into sched_4bsd.c? i don't think it's a good idea to duplicate these
> complicate code for each schedulers.
Ok, after spending quite some thoughts over schedcpu(), I think there
simply is no perfect solution for the moment. Simply moving schedcpu()
back to kern_synch.c seems not very feasible to me, for the following
1. A lot of 4BSD specific defines and functions are used throughout
schedcpu(). If I would move it to kern_synch.c, I'd have to put all
this stuff into sched.h. Moving those to kern_synch.c is not an
option, since they are required by other 4BSD specific functions as
well. Cluttering up sched.h with all those scheduler dependent
defines etc. seems not really nice to me.
2. The largest part of schedcpu() in fact is highly 4BSD specific. The
only really independent parts are:
- increments of l->l_swtime and l->l_slptime
- p_pctcpu calculations
- rlimit checks
4. Even though we might not get rid of p_estcpu in the near future, it
would be sufficient for other schedulers to simply set p_estcpu =
p_pctcpu. There's no need to perform all those nasty calculations
for schedulers not using p_estcpu.
To sum this up: I don't think leaving schedcpu() as it is will lead to
too much code duplication. Not all schedulers will need schedcpu() in
its current incarnation. And it is IMHO the most clean solution for
What do you think?
Faculty of Technology