DragonFly BSD
DragonFly kernel List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: proc extension request: p_sched

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 28 Dec 2003 11:13:16 -0800 (PST)

: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.
:I'll try to rework some of what I've already got to fit into all that.

    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.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]