Re: proc extension request: p_sched

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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

    Right.  A simple set of function pointers in struct scheduler ought
    to cover about 90% of what needs to be done.  I'm sure that some functions
    may also have to be migrated into or out of kern_switch.c to properly
    compartmentalize the user process scheduling functions.

: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.)

    This would be 'stage 3' work.  Stage 1 work would be to compartmentalize
    the existing scheduler (i.e. creating struct scnheduler and making
    everything run through dispatch functions via struct scheduler).  Stage 2
    work would be to add the migration capabilities (including an additional
    function vector in struct scheduler to remove a process and 
    scheduler assignment, and add a process and make a new scheduler
    assignment).  Stage 3 work would be to properly ref-count struct scheduler
    and deal with the fine points of the user interface.

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

    We have a preemptable kernel... that's how interrupt threads are
    scheduled.  It isn't always preemptable... a critical section prevents
    preemption, but it's close enough such that we can achieve near
    hard realtime in the next 6 months as we clean up various pieces of
    code that stay in critical sections for very long periods of time
    (like an interrupt thread when it is running).

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

    Ok. If you want something committable then do it in stages.  The first
    stage should be strictly associated with isolation and compartmentalization
    of the existing scheduler.  That will get 80% of the work done without
    making any major functional changes to the code and we could then commit
    it with fair confidence that we haven't broken anything.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>