Date: Thu, 26 Jun 1997 18:44:25 +0000 (GMT) From: BRiGHTMN <brightmn@a-v25.rh.sunyit.edu> To: Steve Passe <smp@csn.net> Cc: Bob Bishop <rb@gid.co.uk>, hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: interrupt latency Message-ID: <Pine.BSF.3.95q.970626184310.5426D-100000@server.local.sunyit.edu> In-Reply-To: <199707142113.PAA01080@Ilsa.StevesCafe.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970626184310.5426D-100000>