From owner-freebsd-hackers Mon Jul 14 15:44:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA19120 for hackers-outgoing; Mon, 14 Jul 1997 15:44:07 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19037; Mon, 14 Jul 1997 15:42:31 -0700 (PDT) Received: from localhost (brightmn@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id SAA05440; Thu, 26 Jun 1997 18:44:25 GMT Date: Thu, 26 Jun 1997 18:44:25 +0000 (GMT) From: BRiGHTMN To: Steve Passe cc: Bob Bishop , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency In-Reply-To: <199707142113.PAA01080@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk dedicate a 600+$ CPU only to interupt control? doesn't sound very cost effective, that would mean a 2 CPU machine would almost "loose" a CPU... > 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 > > >