Date: Mon, 14 Jul 1997 13:16:06 -0600 From: Steve Passe <smp@csn.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: smp@freebsd.org, hackers@freebsd.org Subject: Re: interrupt latency Message-ID: <199707141916.NAA00523@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Mon, 14 Jul 1997 19:33:51 %2B0200." <199707141733.TAA11310@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > what are the starting and ending event that you are looking for ? > > start: hw_irq, handler (glue code) called ? > end: handler called, driver called ? thats a good question. the problem: in our SMP system an INT may be sent to a CPU that can't enter the kernel because another CPU is currently inside the kernel. this causes a long delay between the time the INT tickels the hardware and the time the ISR actually runs. --- So I guess the 2 points in time are the actual instance of hardware INT and the time the ISR completes. The closest the software can get to determining the start point would be on entry to _XintrNN (isa/apic_vector.s) A convenient stop point would be immediately after the lock is acquired (ie, after GET_MPLOCK in _XintrNN), the completion of the ISR code should be constant. But this hides the time between the actual firing of the hardware INT and the time a CPU accepts it. This could be fairly long if the "accepting CPU" is stuck behing the "giant lock", as hardware INTs are blocked during this time. The "ideal hardware solution" would be a card with a counter per INT source. each counter would be started by an INT, stopped & read via the ISR specific to that INT. I guess 2 cards, PCI & ISA, would be required for a complete solution. And MBs with onboard periphials such as disk and net would hide the most important INTs. WHich suggests an ISA card for the counters with an umbilical cord to attach to the APIC on the MB (a discrete chip with the natoma/triton chipset). --- Having said all this perhaps what I need are repeatable, disk/net IO intensive tests that benefit from latency improvements. -- 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?199707141916.NAA00523>