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
reasons:

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

What do you think?

Regards,
Daniel

-- 
Daniel Sieger
Faculty of Technology
Bielefeld University
wwwhomes.uni-bielefeld.de/dsieger