Date: Mon, 16 Sep 2002 23:27:45 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Harti Brandt <brandt@fokus.gmd.de> 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: <20020916230604.L7230-100000@gamplex.bde.org> In-Reply-To: <20020916135713.K92332-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Sep 2002, Harti Brandt wrote: > On Mon, 16 Sep 2002, Bruce Evans wrote: > > BE>On Mon, 16 Sep 2002, Harti Brandt wrote: > BE>> IMHO all those status update stuff should rather run from a kernel thread. > BE> > BE>This would just increase overheads and indeterminacies IMO (unless you have > BE>more CPUs than things to do). It can be considered a feature that timeouts > BE>are run sequentially on a single CPU. This leaves other CPUs (if any) free > BE>to do useful work. Timeout processing just need to be guaranteed to not > BE>be delayed by more than N msec or so. You can hope than N < 1000.0 / HZ > BE>but probably can't get it (in all cases) when HZ is much larger than the > BE>default. The default of 10 msec is very easy to get (although not to > BE>guarantee) with modern CPUs provided there are no drivers that busy-wait. > > As far as I understand the mii tick routines are used to do status updates > and to (re)negotiate the physical layer. As such I see no problems with > indeterminacies. The indeterminacies are that the negotiations apparently take an indeterminate and/or long time (depending on what the physical layer is doing?) and other things after to wait for them (since the updates are not interrupt driven or even polled in a good way). > My problem is, that I have an application that simulates a satellite link > in the kernel. I use HZ=10000 for this and, well, given the speed of > modern CPUs I expect to have callouts an upper bound of 100usecs on fast > CPUs. Actually this seems to be the case with my current hardware, except > for the xl driver. In this case I'm not yet sure, whether this is a > hardware design bug (reading registers bitwise), in which case we can do > nothing about, or a driver bug (falsely calling DELAY(1)). I tend to > assume the later... Unfortunately, the worst case for current hardware seems to be no better than for old hardware once you leave the CPU core. See my mail about DELAY() taking more than 150 usec just because it accesses the isa bus 3 times while fxp is accessing the pci bus. Anything that does bus accesses risks getting such delays occasionally. The PCI latency timer is supposed to limit them but doesn't seem to work so well on one of my systems. Some recent debugging output on an Athlon1600XP !SMP: Sep 14 22:24:07 besplex kernel: new getit_delta_max = 4012 nsec [above is for first call after booting] [... more low values while starting up] Sep 14 22:28:24 besplex kernel: new getit_delta_max = 66186 nsec Sep 14 22:28:24 besplex kernel: new getit_delta_max = 83266 nsec Sep 14 22:28:29 besplex kernel: new getit_delta_max = 101650 nsec Sep 14 22:28:29 besplex kernel: new getit_delta_max = 102266 nsec Sep 14 22:40:31 besplex kernel: new getit_delta_max = 136031 nsec Sep 14 22:40:37 besplex kernel: new getit_delta_max = 162933 nsec Sep 15 02:01:28 besplex kernel: new getit_delta_max = 163980 nsec Sep 15 02:01:47 besplex kernel: new getit_delta_max = 168108 nsec Sep 15 02:05:22 besplex kernel: new getit_delta_max = 186455 nsec This shows the time taken by getit() (which is the heart of DELAY()) while the lock is held. My version also disables interrupts. Only each new maximum is reported. 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?20020916230604.L7230-100000>