Date: Sat, 12 Oct 2002 16:31:47 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Julian Elischer <julian@elischer.org>, Hiten Pandya <hiten@angelica.unixdaemons.com>, Terry Lambert <tlambert2@mindspring.com>, Jeff Roberson <jeff@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Scheduler patch, ready for commit. Message-ID: <Pine.NEB.3.96L.1021012162730.97794L-100000@fledge.watson.org> In-Reply-To: <20021012152434.U30714-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Oct 2002, Jeff Roberson wrote:
> > If done on the fly, this would require freeing all the allocated procs
> > in the uma cache and changing the size of the zone, and re-filling it,
> > and replacing all the existing procs with the new larger ones.. hardly a
> > likely scenario.
> > Pretty obviously the additional storage is in the form of an extra blobb
> > hanging off the proc/kse/ksegrp/thread structures as needed. (Unless the
> > scheduler can make use of a couple of void * 'p_sched_private' type
> > fields we can preallocate.
>
> Is there really demand for on the fly scheduler changes? I guess I
> always thought of it as a neat trick and not something useful. It
> doesnt seem like it's worth the overhead for the extremely small number
> of scenarios where it's needed.
It seems to me that there are several levels of "pluggability"
(1) Source code pluggable. You modify the source to do the plugging.
Also known as the patchset.
(2) Compile pluggable. You don't have to modify existing code, but you do
have to add new code in a module; the system is designed to easily
allow this extensibility.
(3) Boot-time pluggable. You can insert a module by linking it to the
kernel, or by loading it with the boot loader.
(4) Run-time pluggable. You can link it to the kernel, load it prior to
boot, or load it after boot.
There's also open questions about removal. With the MAC Framework, we've
taken it to (4), although there are some policies that by definition can't
be loaded after system start since they need the opportunity to impact the
system from inception, as well as policies that can't be unloaded.
Likewise with file systems, device drivers, etc. My personal feeling is
that it would be nice, eventually, to be able to do boot-time selectable
schedulers, but that that is about where you hit diminishing returns: to
do more, it requires a lot more work with a lot less return, since you
have to do a lot more in the way of allocation management, cleanup, not to
mention whether you either "compose" or "replace" scheduling policies,
etc.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
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?Pine.NEB.3.96L.1021012162730.97794L-100000>