Re: proc extension request: p_sched

[Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>]

Hi !

I've CC'd this to kernel as well, as I think it is the appropriate list.
Sorry for this zic-zac cross-posting.

>     In fact I was talking about kernelspace userland schedulers (what
>     you have been working on).  e.g. kern_switch.c and friends.
>     And, also, I was indeed talking about being able to switch the scheduler
>     on the fly.

>     It would actually be very easy to do in DFly because the
>     userland scheduler always uses the LWKT scheduler to do the actual
>     scheduling, and the LWKT scheduler is fixed.
Good that this is clarified. I was a bit confused.
OK, now I understand I'v been missing a whole bunch of possibilities.
Argh, I'm feeling retarded. *Clap*. Of course, now I got it.

>     This means, theoretically, that you can have multiple userland
>     schedulers operating in tandem.  While we would not necessarily use it
>     that way (and, certainly there would be issues with one hogging the other),
>     the ability operate multiple userland schedulers simultaniously would
>     make transitioning to a new scheduler on a live system very easy.
And the entry points from kern_switch.c should then be changed to be
some sort of dispatcher/multiplexer depending on p->p_scheduler ?
For the transition to work, the system and the schedulers should have
some helper functions - giving information about currently managed
processes, initialzing runqueues with some list of runnable processes
and the like.
And now something on transition policies:
The easiest I can think of is to keep reference counts on schedulers
and as long as there are processes (even under control of LWKT)
mangaged by scheduler foo, foo may not be discarded at all.
But this would mean that a transition get delayed arbitrarily long.
And should the scheduler be selectable per-process, per-processgroup
or even just per-session ? I'd say per-processgroup. (Jobs should
be scheduled uniformly is my rationale here.)

>     The same scheme could also theoretically give us the ability to implement
>     a hard real-time scheduler that runs in tandem with the 'standard' userland
>     scheduler, for example, as well as other sorts of resource-sensitive
>     schedulers.
Hmm, but hard real-time would need support by LWKT. And AFAIK would need
a preemptable kernel to have warranties on response times.
I really don't see how this would apply here.
But we could implement some SFQ-scheduler to warrant some distribution
of (userspace-)time between different (userland-)subsystems.

>     Yes, the idea would be that p_scheduler would simply be inherited by
>     the children (no allocations required), and an API call through
>     p_scheduler would be used to allocate p_sched if required.
Alright.

I'll try to rework some of what I've already got to fit into all that.

Cheers
Peter

--
<peter.kadau@xxxxxxxxxxxxxxxx>

Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration

Tel: +49 7071 601 598
Fax: +49 7071 601 616