Date: Wed, 17 Jul 2002 04:45:38 -0700 From: Luigi Rizzo <rizzo@icir.org> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: arch@FreeBSD.ORG Subject: Re: proposed changes to kern_switch.c and kern_synch.c Message-ID: <20020717044538.A9282@iguana.icir.org> In-Reply-To: <20020717105433.GB29269@over-yonder.net>; from fullermd@over-yonder.net on Wed, Jul 17, 2002 at 05:54:34AM -0500 References: <20020716235216.B6785@iguana.icir.org> <20020717105433.GB29269@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 17, 2002 at 05:54:34AM -0500, Matthew D. Fuller wrote: ... > Luigi Rizzo, and lo! it spake thus: > > > > --- Re. the multi-scheduler architecture --- > > > > The general idea is to make the process/thread/kse scheduler > > a replaceable piece of the kernel, requiring no modifications > > to the "struct proc", and with the ability of switching from > > one scheduler to another one at runtime (this both for testing > > purposes and for whatever need may arise). > > Random related thoughts: > > 1) From the work you've done on this already, how difficult would you > expect it to be to do this in such a way that you could have multiple > (>2) schedulers around, loading and unloading at will (when disabled, of > course) through KLD's? it is basically already done -- schedulers are loaded and initialized via SYSINIT, and when you switch to another one all references to the old one are removed and data structures freed. It is just a matter of providing the module glue. > 2) How much unavoidable overhead is there in switching between the > schedulers? Could it get low enough that it might be meaningful to, > instead of writing One True Scheduler, instead write 3 or 4 different > optimized ones, and have some intelligence to switch between them > automagically as load demands? you need to move all processes from one scheduler to another, so it is O(n) overhead. Frankly i do not believe it is very interesting to switch between different schedulers at runtime other than for testing purposes. What _might_ be more interesting is to use multiple schedulers in a hierarchical fashion, e.g. WFQ within each priority class, or priority among threads or processes belonging to the same scheduling entity (KSEG or process group). Not that I am an advocate of that either, i generally prefer flat structures. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020717044538.A9282>