DragonFly kernel List (threaded) for 2003-12
Re: proc extension request: p_sched
: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.