Date: Wed, 19 Jul 2000 14:23:37 +0930 From: Greg Lehey <grog@lemis.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719142337.L12072@wantadilla.lemis.com> In-Reply-To: <200007190449.VAA21651@mass.osd.bsdi.com> References: <20000719135730.J12072@wantadilla.lemis.com> <200007190449.VAA21651@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000719142337.L12072>