From owner-freebsd-hackers Mon Jul 14 14:14:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14675 for hackers-outgoing; Mon, 14 Jul 1997 14:14:59 -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 OAA14653; Mon, 14 Jul 1997 14:14:36 -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 PAA01080; Mon, 14 Jul 1997 15:13:49 -0600 (MDT) Message-Id: <199707142113.PAA01080@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Bob Bishop cc: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency In-reply-to: Your message of "Mon, 14 Jul 1997 21:38:11 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 15:13:48 -0600 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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