Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jul 2000 21:49:32 -0700
From:      Mike Smith <msmith@freebsd.org>
To:        Greg Lehey <grog@lemis.com>
Cc:        arch@FreeBSD.ORG, smp@FreeBSD.ORG
Subject:   Re: Tidying up the interrupt registration process 
Message-ID:  <200007190449.VAA21651@mass.osd.bsdi.com>
In-Reply-To: Your message of "Wed, 19 Jul 2000 13:57:30 %2B0930." <20000719135730.J12072@wantadilla.lemis.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.  There are two separate things that a 'fast' 
interrupt handler seeks to achieve: reduced and constrained interrupt 
latency.

Allowing 'fast' interrupts to be shared removes any hope of constraining 
latency, as well as increasing it.  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.

> 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.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]




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?200007190449.VAA21651>