From owner-freebsd-smp  Mon Jul 14 12:17:33 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA08882
          for smp-outgoing; Mon, 14 Jul 1997 12:17:33 -0700 (PDT)
Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08860;
          Mon, 14 Jul 1997 12:17:10 -0700 (PDT)
Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1])
	by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id NAA00523;
	Mon, 14 Jul 1997 13:16:06 -0600 (MDT)
Message-Id: <199707141916.NAA00523@Ilsa.StevesCafe.com>
X-Mailer: exmh version 2.0gamma 1/27/96
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 
In-reply-to: Your message of "Mon, 14 Jul 1997 19:33:51 +0200."
             <199707141733.TAA11310@labinfo.iet.unipi.it> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 Jul 1997 13:16:06 -0600
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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