Date: Sat, 12 Oct 2002 14:16:49 -0700 From: Luigi Rizzo <rizzo@icir.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: <20021012141649.A91655@carp.icir.org> In-Reply-To: <20021012152434.U30714-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Sat, Oct 12, 2002 at 03:27:19PM -0400 References: <Pine.BSF.4.21.0210121201110.63899-100000@InterJet.elischer.org> <20021012152434.U30714-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 12, 2002 at 03:27:19PM -0400, 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. if you would actually have a look at how i did it in stable, the codeto support that is just trivial, and the only no overhead in supporting this capability during normal operation is one indirect (as opposed to one direct) function call for each of the scheduler functions, which do not occur very often, and disappear in the noise compared to the rest of the work done by the scheduling code. Besides, the indirect function call is something we are already paying for multiple times on each packet handled by the network stack -- the protocol input routines are handled like this, so is the firewall call, so are the various if_* functions (interrupts, if_start ...), in netgraph, and wherever there is a loadable kernel module. Network events happen in the order of 100,000 times per second on a busy box, whereas scheduling decisions are probably taken 1-2 order of magnitude less frequently. Not that we _need_ to switch schedulers at runtime, but it is terribly conveninent when you are doing testing, and it basically comes for free when you want to make schedulers loadable as KLDs. And since most of the system is going that route i do not see why there are objections to this. 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?20021012141649.A91655>