Loadable Scheduler in Freebsd

[Daniel Eischen]

On Mon, 8 Nov 2004, Julian Elischer wrote:
>
>
> Devesh Shah wrote:
>
> >  Thanks to all of you who have responded to my initial question. I
> >  would be interested in looking at such implementation if possible. I
> >  see there are about 18 other kernel files that call common scheduler
> >  interface routines defined in ul.c and bsd.c such as sched_nice(),
> >  sched_sleep(), sched_wakeup() etc. These would have to be
> >  transitioned to call appropriately when new scheduler is loaded and
> >  disable the old scheduler.
>
> We would simply change them to call via pointers.. no big deal.
> It might even be a saving in some cases because you could skip
> calling if the pointer is NULL instead of always calling and discovering
> that the function is only a stub that does nothing..
>
>  > Also, init (in init_main.c) process is
> >  handcrafted and given the address of kse in thread structure. These
> >  kses are defined differently for both schedulers.
> >
> what revision are you looking at?  init_main.c calls schedinti()
> that is in the scheduler, which does this..
>
> A lot of this was changed just prior to 5.3. The kse structure is
> unknown outside of the scheduler. It is only defined within
> sched_4bsd or sched_ule.c. so init_main.c has no idea what is in it.
> (or even that it exists) There is not even any requirement that teh even
> BE any per-thread scheduelr private structure. (struct kse == struct
> td_sched
> for historical reasons.. I have not yet decided which name will 'survive').
>
> You COULD switch schedulers at run time but you'd need to be able to
> extract each thread from the old scheduler and inject it into the new
> scheduler, while holding all other things the same.
>
> You would also need to change the allocation code to allocate the kse
> (a.k.a td_sched) structure separatly, so that it could be freed and
> replaced by one
> that is suitable for the new scheduler. This would not be a big task but
> the code
> to extract the threads and put them into the new scheduler would be
> quite interesting.

If the schedulers were aware of the "selected" scheduler (or perhaps
the previous scheduler), they could do the thread removal and insertions
themselves I suppose.

-- 
Dan Eischen