Date: Mon, 16 Sep 2002 15:42:06 +0200 (CEST) From: Harti Brandt <brandt@fokus.gmd.de> To: Bruce Evans <bde@zeta.org.au> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, 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: <20020916153154.C92332-100000@beagle.fokus.gmd.de> In-Reply-To: <20020916230604.L7230-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Sep 2002, Bruce Evans wrote: BE>On Mon, 16 Sep 2002, Harti Brandt wrote: BE> BE>> On Mon, 16 Sep 2002, Bruce Evans wrote: BE>> BE>> BE>On Mon, 16 Sep 2002, Harti Brandt wrote: BE>> BE>> IMHO all those status update stuff should rather run from a kernel thread. BE>> BE> BE>> BE>This would just increase overheads and indeterminacies IMO (unless you have BE>> BE>more CPUs than things to do). It can be considered a feature that timeouts BE>> BE>are run sequentially on a single CPU. This leaves other CPUs (if any) free BE>> BE>to do useful work. Timeout processing just need to be guaranteed to not BE>> BE>be delayed by more than N msec or so. You can hope than N < 1000.0 / HZ BE>> BE>but probably can't get it (in all cases) when HZ is much larger than the BE>> BE>default. The default of 10 msec is very easy to get (although not to BE>> BE>guarantee) with modern CPUs provided there are no drivers that busy-wait. BE>> BE>> As far as I understand the mii tick routines are used to do status updates BE>> and to (re)negotiate the physical layer. As such I see no problems with BE>> indeterminacies. BE> BE>The indeterminacies are that the negotiations apparently take an BE>indeterminate and/or long time (depending on what the physical layer is BE>doing?) and other things after to wait for them (since the updates are BE>not interrupt driven or even polled in a good way). But you have these indeterministics either way, because the callouts are serialized. If a negotiation blocks, then it either blocks all callouts (this is what we have currently) or only all other negotiations/status updates (if we use a kernel thread). Both of those variants are bad, but the first is worse than the second. BE>Unfortunately, the worst case for current hardware seems to be no better BE>than for old hardware once you leave the CPU core. See my mail about BE>DELAY() taking more than 150 usec just because it accesses the isa bus BE>3 times while fxp is accessing the pci bus. Anything that does bus accesses BE>risks getting such delays occasionally. The PCI latency timer is supposed BE>to limit them but doesn't seem to work so well on one of my systems. Some BE>recent debugging output on an Athlon1600XP !SMP: [SNIP] I suppose, that this depends on the hardware you use. My problem is, that the xl status update function is broken, no matter what hardware you use. If I comment out this function, my system does just what it is supposed to do - I receive the 100usec timer ticks at my netgraph node with a jitter of around 20usecs which is just fine. My argument is that we shouldn't allow broken drivers because hardware may be broken. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de 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?20020916153154.C92332-100000>