Date: Mon, 14 Jul 1997 15:13:48 -0600 From: Steve Passe <smp@csn.net> To: Bob Bishop <rb@gid.co.uk> Cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency Message-ID: <199707142113.PAA01080@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Mon, 14 Jul 1997 21:38:11 BST." <l0302090aaff03e27db0e@[194.32.164.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > >Can anyone recommend a test suite/methodology for evaluating interrupt > >latency? > >I have some ideas for improving the (currently poor) int response of the SMP > >kernel, but need a way to determine if I am actually bettering things. > > A digital output port and an oscilloscope, logic analyser or something > similar. Any other (ie non-hardware) method is just inviting confusion. I tend to agree, but I think the "hardware" solution could be a 4 CPU MB. I was just discussing another possibility that goes as follows: program the first 2/3 CPUsas a 2/3 CPU SMP system. program the 4th CPU as a standalone INT receiver/statistic counter. program the APIC to send all INTs to the 4th CPU. the 4th CPU could then do nothing but accept INTs from the APIC, record the time, then dispatch them to the APIC bus, in a manner identical to that used by the IO APIC. The mainline ISR code could then be modified to send an IPI to the 4th CPU when the ISR was done. The 4th CPU would record the total time and record it in global memory. The 1st 3 CPUs wouldn't have a clue that they weren't getting them from the APIC, and the 4th CPU could service the real INTs almost as fast as they occur. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707142113.PAA01080>