Date: Fri, 04 Jan 2002 07:24:48 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-arch@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: SMPng: Interrupt Latency Issues Message-ID: <20020104072448.I561@gsmx07.alcatel.com.au> In-Reply-To: <683.1010049413@critter.freebsd.dk>; from phk@critter.freebsd.dk on Thu, Jan 03, 2002 at 10:16:53AM %2B0100
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Jan-03 10:16:53 +0100, Poul-Henning Kamp <phk@critter.freebsd.dk> wrote: >There are basically two things to getting good interrupt latency: > > 1. An architecture making it possible. ... >I think we are on track to #1. Does this mean FreeBSD is dropping support for PC-compatible hardware? :-) (For that matter, PALcode also worsens interrupt latency on the Alpha). >My main contribution will probably be in trying to establish a >metrology to document the result, but to the extent time allows I >will participate and help where I can. This needs to be cross-platform. We also need a way for developers to measure (at least approximately) interrupt latency without needing USD1K timer boards - otherwise they can't assess the impact of any changes they make without involving you. For example, if you're using an i8254 as the master clock, you can get a reasonable estimate of interrupt latency by reading the i8254 counter at the start of hardclock(). This has a (fixed) overhead of a couple of usec, a resolution of ~840nsec and can only measure clock interrupt latency in specific (though common) configurations. A more general approach approach is to read the TSC as early as possible in the interrupt process and then again at the beginning of the device-level interrupt handler. This suffers from the vagaries of TSC frequency and can't measure the delay from interrupt assertion to the beginning of the software vector, but has reasonable resolution and will work on any interrupt and most CPUs. Both these approaches are probably "Good Enuf" for our purposes. I don't believe the object is a hard real-time kernel so a few usec slop in the interrupt latency probably doesn't matter. We just need to avoid latency spikes in the msec region. As for hardware approaches: A dedicated timer card like the PCI Pamette is obviously the best, but most pricey, solution. Maybe one of the hardware gurus would like to design and manufacture a simple PCI card that is capable of generating an interrupt and lets you read a 32-bit time-since-interrupt counter. (Or something a bit fancier that generates an interrupt, accepts an acknowledge signal and keeps track of the minimum/maximum/mean/median/variance internally). Both these approaches can also be done more cheaply and less accurately via the parallel port. The oscilloscope approach will let you measure average latencies but, unless you have a fancy digital CRO or logic analyser, isn't going to measure outliers - which are at least as important. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020104072448.I561>