On Mon, Feb 19, 2007 at 01:14:56PM +0100, Daniel Sieger wrote:

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

I think leaving the calculations there is probably the best option at this
point. One thing that does concern me is that p_pctcpu and p_estcpu are per
process. I'm thinking that they should be per LWP. One thing that having
them per process does for us is to inflict a penalty on multithreaded
applications: since they have more threads and can use more CPU time than
single threaded apps. (It's also quite ugly from a locking perspective -
but that's more of an implementation detail.)

What would we need to to make those per-LWP? Would it make sense to have
some kind of concurrency limit for threaded applications?

Cheers,
Andrew