Loadable Scheduler in Freebsd

[Julian Elischer]

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.

>
>
>  For my project perspective, I would like to have this functionality
>  of loadable scheduler though it may not deem necessary from a cleaner
>  kernel developement such as Freebsd. I agree, process state can not
>  be guaranteed to be prserverd as they are different scheduler

>
>
>  thanks, -devesh
>
>
>
>  ----- Original Message ----- From: "Luigi Rizzo" <rizzo at icir.org> To:
>  "Devesh Shah" <shah at docomolabs-usa.com>;
>  <FreeBSD-hackers at FreeBSD.org> Sent: Saturday, November 06, 2004 11:35
>  AM Subject: Re: Loadable Scheduler in Freebsd
>
>
> > On Sat, Nov 06, 2004 at 11:21:23AM -0800, John-Mark Gurney wrote:
> >
> >> Devesh Shah wrote this message on Thu, Nov 04, 2004 at 15:22
> >> -0800:
> >>
> >>> Based on the SYSINIT framework, I have made ULE scheduler as a
>
>  loadable module but have not quite
>
> >>> figured how to migrate from default 4bsd to newly loaded ule
> >>> scheduler
>
>  or is it possible at all.
>
> >> As someone suggested, switches schedulers would be very complex..
> >>
> >
> > actually i beg to differ, as we implemented it in 4.x back in
> > summer 2002 -- our code allowed to switch between schedulers at
> > runtime, and we had a prototype Proportional Share (PS for short)
> > scheduler which you could use instead of the standard BSD one.
> >
> > I don't see much of a problem in switching schedulers at runtime,
> > if you properly hide the scheduler's internal information from the
> > process' descriptor, which is what we did. At which point,
> > switching scheduler only requires to rearrange the scheduler's
> > information with no impact on the process descriptor or state. Of
> > course you can't expect "guarantees" to be preserved across
> > switches,if nothing else because they might well be measured in
> > different way.
> >
> > if you wonder why our code was not committed, it was because there
> > was not, and i think there is not yet, a good theoretical framework
> > for multiprocessor proportional share scheduling, so our PS
> > scheduler (note, not the scheduler abstraction framework, only the
> > PS scheduler instance) would not work in the SMP case, and this
> > apparently was a requirement for inclusion.
> >
> > cheers luigi
>
>
>  _______________________________________________
>  freebsd-hackers at freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To
>  unsubscribe, send any mail to
>  "freebsd-hackers-unsubscribe at freebsd.org"