Date: Mon, 16 Sep 2002 14:03:55 +0200 (CEST) From: Harti Brandt <brandt@fokus.gmd.de> To: Bruce Evans <bde@zeta.org.au> Cc: Harti Brandt <brandt@fokus.gmd.de>, 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: <20020916135713.K92332-100000@beagle.fokus.gmd.de> In-Reply-To: <20020916214755.K6839-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, Poul-Henning Kamp wrote: BE>> BE>> PK>But couldn't some of this be due to evil DELAY() or locking in the BE>> PK>in the timeout routine ? In that case it's only the duration, not BE>> PK>the CPU usage which is .8% ? BE>> BE>> In case of the xl driver it is a problem with DELAY(). One xl_mii_readreg BE>> needs 184 DELAY(1) calls, each of which takes around 9usecs. The mii_tick BE>> needs several readregs. Just for testing I have converted all these DELAYs BE>> to use busy wait on the TSC. This cuts down the readreg() time to BE>> 350usecs! BE> BE>This is quite different from fxp_miibus_readbus() where there is just 1 BE>DELAY(10) call in a loop which is iterated 0 times in the best case. BE>Anything that makes 184 DELAY(1) calls will deservedly suffer from DELAY(1) BE>taking much longer than 1 usec. BE> 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. 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... 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?20020916135713.K92332-100000>