From owner-freebsd-arch Sat Oct 12 13:32:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D9ED37B401; Sat, 12 Oct 2002 13:32:46 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92EEC43EB7; Sat, 12 Oct 2002 13:32:44 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9CKVlOo044182; Sat, 12 Oct 2002 16:31:47 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 12 Oct 2002 16:31:47 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jeff Roberson Cc: Julian Elischer , Hiten Pandya , Terry Lambert , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Scheduler patch, ready for commit. In-Reply-To: <20021012152434.U30714-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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