From owner-freebsd-current  Thu Sep 24 21:09:30 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id VAA21922
          for freebsd-current-outgoing; Thu, 24 Sep 1998 21:09:30 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA21916;
          Thu, 24 Sep 1998 21:09:24 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA32518;
	Fri, 25 Sep 1998 14:09:03 +1000
Date: Fri, 25 Sep 1998 14:09:03 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199809250409.OAA32518@godzilla.zeta.org.au>
To: bde@zeta.org.au, cgull@owl.org, gibbs@plutotech.com,
        shimon@simon-shapiro.org
Subject: Re: options DPT_LOST_IRQ
Cc: current@FreeBSD.ORG, eivind@yes.no, mcdougall@ameritech.net,
        sos@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>> In any case, ix86's can not process an interrupt in less than about 5
>> i/o times (perhaps 2.5-6 usec) in the best case.  If a device raises
>> and lowers its 64 times in < 64 usec, then at best the handler would see
>> about 64/2.5 separate interrupts.  This is with a generous allocation of
>> 1 i/o time for device-specific interrupt handling.
>
>This isn't true for systems/software using APICs, no?
>
>A quick perusal of the code seems to show that they use memory-mapped
>I/O, less of it than a PIC, and IIRC, it's not across an
>ISA-speed bus.

I don't know the details.  I would be surprised if it were much faster,
since there are extra overheads for SMP.  Even an immediately successful
spinlock normally takes at least as long as an uncached memory reference.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message