From owner-cvs-all Mon Sep 16 6:42:15 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 9A5B237B400; Mon, 16 Sep 2002 06:42:13 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0976443E42; Mon, 16 Sep 2002 06:42:12 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g8GDg6h25631; Mon, 16 Sep 2002 15:42:06 +0200 (MEST) Date: Mon, 16 Sep 2002 15:42:06 +0200 (CEST) From: Harti Brandt To: Bruce Evans Cc: Poul-Henning Kamp , Josef Karthauser , "David O'Brien" , , Subject: Re: cvs commit: src/sys/kern kern_timeout.c In-Reply-To: <20020916230604.L7230-100000@gamplex.bde.org> Message-ID: <20020916153154.C92332-100000@beagle.fokus.gmd.de> 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, 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