Date: Tue, 17 Sep 2002 06:39:04 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Archie Cobbs <archie@dellroad.org>, Josef Karthauser <joe@FreeBSD.org>, "David O'Brien" <obrien@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_timeout.c Message-ID: <20020917061137.V8586-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0209161234200.96232-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Sep 2002, Julian Elischer wrote: > On Mon, 16 Sep 2002, Poul-Henning Kamp wrote: > > > > I have wondered if periodic events should be handled differently, > > or at least separately from one-shots, but that is also just an > > idea. > > > > I think what we need more than anything, is somebody gathering more > > hard data and analyzing more... > > The original idea of softclock was to try and have the running of > timeouts asynchronously fromt he hardware clock, and teh hardware clock > could actually fire during softclock.. This still happens too, with the hardclock interrupt having a better chance than it used to (except in my version where it has approximately the same chance as in RELENG_4). hardclock() is a fast interrupt in interrupt handler SMPng, so it isn't blocked by anything except spinlocks and critical_enter(). softclock() is a normal low priority interrupt handler (ithread) that gets scheduled by hardclock() every 1/HZ. The problems are that it sometimes holds Giant for a long time, and most interrupt handlers can't run while Giant is held. Splitting it up into threads of any priority won't help anything except some of these threads run earlier, which isn't very useful since timeouts are supposed to have lowest priority among interrupt handlers. More important things like higher priority interrupts and user processes in the kernel (on other CPUs) would still have to wait for Giant while the hog timeout handlers (now threads instead of calls from softclock()) hold Giant. > However I think that now that we have kernel threads there is a good > case that can be made for running such events in a high priority thread > and limiting the softclock to scheduling it if there is something to do. > (and maybe ticking over a pointer or two) Hardclock() is a normal high priority interrupt handler (ithread) in my version (one of the few that are INTR_MPSAFE so they aren't blocked by Giant), so it has much the same priority as in RELENG_4 and -current with SMPog. It is just pessimized by context switching. The pessimization isn't a problem for the default HZ if 100 but might be one for a much larger HZ. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020917061137.V8586-100000>