> Hello,
> I have made a small patch for further scheduler works. Shortly what it does:
> 
> 1) Add sched_rq, sched_proc_sd, sched_lwp_sd in struct cpu_data, proc, lwp.
> These would be a pointers for dynamically allocated scheduler-specific data.
> Currently, not used for SCHED_4BSD (yet).
> For now, there are dummy functions in sched_4bsd.c, IMHO it would be good to
> nano-optimize these useless calls, even if they aren't expensive.

i don't think it's worth to have #ifdef for them.

> 4) Move old LWP enqueue from mi_switch() to sched_nextlwp(). Other
> implementations of scheduler could (and will) do that differently. In this
> case, maybe it would worth changing the name, eg, to sched_switch()?

i prefer to have separate calls for separate operations.
ie. "enqueue for yielding" and then sched_nextlwp().

> 1. Currently there are two general functions sched_lock() and sched_unlock()
> for runqueue (and all the scheduler) locking. From now, one is going to use a
> runqueues per CPU, hence this should be changed.
> a) Add a kmutex_t in struct cpu_data (there is a general MI data) and it
> would be a generic lock for runqueue.
> b) Add kmutex_t in scheduler-specific area and move sched_lock/sched_unlock
> to scheduler module. This would be more flexible, IMHO.
> In any case, prototype would probably change to:
>     static inline void sched_lock (struct cpu_info *ci, const intheldmutex);
> Any other suggestions?

do you have any specific use of b)?

> 2. As already discussed, currently, there is a problem with p_estcpu and
> p_pctcpu, which should be scheduler-independent. As mentioned, there is also
> a ccpu value, which is SCHED_4BSD specific. These are used in ps(1), top(1),
> etc. It would be good to find a solution what and how to deal with these. All
> suggestions are welcome.

just FYI: i changed userland-visible values of p_estcpu while ago
and haven't heard any problems about it since then.

YAMAMOTO Takashi