From owner-freebsd-arch Tue Jul 18 21:53:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 682A937B99B; Tue, 18 Jul 2000 21:53:40 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id OAA40543; Wed, 19 Jul 2000 14:23:37 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 14:23:37 +0930 From: Greg Lehey To: Mike Smith Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719142337.L12072@wantadilla.lemis.com> References: <20000719135730.J12072@wantadilla.lemis.com> <200007190449.VAA21651@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190449.VAA21651@mass.osd.bsdi.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 21:49:32 -0700, Mike Smith wrote: >>> You should not be able to register a 'fast' handler on any source >>> with anything else attached, nor anything else on a source that has >>> a 'fast' handler already registered. Yes, this does impose some >>> configuration constraints on the system, but there are few viable >>> alternatives. >> >> You haven't really explained that. Sure, if you have more than one >> interrupt on an IRQ, it will take longer, but it will still ensure >> that nothing else interrupts in the meantime. You can't compare this >> to the current fast interrupt scheme which limits you to one interrupt >> handler, because the hardware reality isn't like that. You need to >> compare it to the alternative of a shared slow interrupt handler: >> clearly a fast interrupt handler will still be faster. And Warner >> produced a valid example of where it would make a difference. > > This is not correct. You need to be more specific in "this". > There are two separate things that a 'fast' interrupt handler seeks > to achieve: reduced and constrained interrupt latency. Right. > Allowing 'fast' interrupts to be shared removes any hope of > constraining latency, as well as increasing it. You're being rather categorical there. As I said, it's a tradeoff. > Note also that a 'fast' handler may be computationally expensive - > the 'fast' criterion has to do with how it is invoked, not how it > runs. Indeed. Much of your hope lies in the wise use of the resource. In fact, I'm astounded how much code there is in siointerrupt. >> As regards sharing fast and slow interrupts on the same IRQ: I can see >> reasons for wanting to do this as well. I don't want to have to write >> the code, though :-) > > It would be relatively trivial, actually, since the dispatcher that > invokes the actual interrupt thread in the 'not-fast' case is really a > 'fast' interrupt handler. No, that's not correct. You set a fast interrupt in icu_setup() by passing the INTR_FAST flag. Slightly simplified: int icu_setup(int intr, inthand2_t *handler, void *arg, u_int *maskptr, int flags) { ... if (flags & INTR_FAST) { vector = TPR_FAST_INTS + intr; setidt(vector, fastintr[intr], SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); } else { vector = TPR_SLOW_INTS + intr; setidt(vector, slowintr[intr], SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); The call to set the mux (in add_intrdesc) is: if (icu_setup(irq, intr_mux, head, 0, 0) != 0) return (-1); So it's a slow interrupt. But you might be right that it would be easier to do than I thought. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message