From owner-cvs-all Mon Sep 16 13:30:59 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08D8537B400; Mon, 16 Sep 2002 13:30:58 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71A8643E4A; Mon, 16 Sep 2002 13:30:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA15723; Tue, 17 Sep 2002 06:30:42 +1000 Date: Tue, 17 Sep 2002 06:39:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Poul-Henning Kamp , Archie Cobbs , Josef Karthauser , "David O'Brien" , , Subject: Re: cvs commit: src/sys/kern kern_timeout.c In-Reply-To: Message-ID: <20020917061137.V8586-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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