Loadable Scheduler in Freebsd

[Devesh Shah]

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

 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