From: Jesse Pollard <jesse@cats-chateau.net>
To: "Michael Frank" <mhf@linuxmail.org>,
"Matt Mackall" <mpm@selenic.com>,
"Grover, Andrew" <andrew.grover@intel.com>
Cc: "Helge Hafting" <helgehaf@aitel.hist.no>, linux-kernel@vger.kernel.org
Subject: Re: Why no interrupt priorities?
Date: Fri, 27 Feb 2004 14:53:45 -0600 [thread overview]
Message-ID: <04022714534500.12104@tabby> (raw)
In-Reply-To: <opr31mmcvk4evsfm@smtp.pacific.net.th>
On Friday 27 February 2004 13:19, Michael Frank wrote:
> On Fri, 27 Feb 2004 12:55:55 -0600, Matt Mackall <mpm@selenic.com> wrote:
> > On Fri, Feb 27, 2004 at 09:44:44AM -0800, Grover, Andrew wrote:
> >> > From: Helge Hafting [mailto:helgehaf@aitel.hist.no]
> >> >
> >> > Grover, Andrew wrote:
> >> > > Is the assumption that hardirq handlers are superfast also
> >> >
> >> > the reason
> >> >
> >> > > why Linux calls all handlers on a shared interrupt, even if
> >> >
> >> > the first
> >> >
> >> > > handler reports it was for its device?
> >> >
> >> > No, it is the other way around. hardirq handlers have to be superfast
> >> > because linux usually _have to_ call all the handlers of a shared irq.
> >> >
> >> > The fact that one device did indeed have an interrupt for us
> >> > doesn't mean
> >> > that the others didn't. So all of them have to be checked to be safe.
> >>
> >> If a device later in the handler chain is also interrupting, then the
> >> interrupt will immediately trigger again. The irq line will remain
> >> asserted until nobody is asserting it.
> >>
> >> If the LAST guy in the chain is the one with the interrupt, then you
> >> basically get today's ISR "call each handler" behavior, but it should be
> >> possible to in some cases to get less time spent in do_IRQ.
> >
> > Let's imagine you have n sources simultaneously interrupting on a
> > given descriptor. Check the first, it's happening, acknowledge it,
> > exit, notice interrupt still asserted, check the first, nope, check
> > the second, yep, exit, etc. By the time we've made it to the nth ISR,
> > we've banged on the first one n times, the second n-1 times, etc. In
> > other words, early chain termination has an O(n^2) worst case.
>
> With level triggered you can just walk the chain, exit at the end of the
> first cycle and should the IRQ still be asserted you just incur the
> overhead of exit and reentry of the ISR.
>
> Even with edge, I would not check alwasy from the beginning of the chain...
You should... after all that first entry in the chain has the highest priority
next prev parent reply other threads:[~2004-02-27 21:00 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-27 17:44 Why no interrupt priorities? Grover, Andrew
2004-02-27 18:15 ` Chris Friesen
2004-02-27 18:42 ` Richard B. Johnson
2004-02-27 19:42 ` Michael Frank
2004-02-27 19:11 ` Michael Frank
2004-02-27 18:55 ` Matt Mackall
2004-02-27 19:09 ` Tim Hockin
2004-02-27 20:29 ` Matt Mackall
2004-02-27 19:19 ` Michael Frank
2004-02-27 20:53 ` Jesse Pollard [this message]
2004-02-29 9:43 ` Michael Frank
2004-03-01 16:57 ` Jesse Pollard
2004-03-01 17:35 ` Michael Frank
2004-03-02 15:25 ` Jesse Pollard
-- strict thread matches above, loose matches on Subject: below --
2004-02-27 11:37 Etienne Lorrain
2004-02-27 13:24 ` Michael Frank
[not found] <mailman.1077822002.21081.linux-kernel2news@redhat.com>
2004-02-27 8:00 ` Pete Zaitcev
2004-02-27 1:36 Grover, Andrew
2004-02-27 3:02 ` Randy.Dunlap
2004-02-29 8:32 ` Michael Frank
2004-02-29 8:36 ` Arjan van de Ven
2004-02-29 9:52 ` Michael Frank
2004-02-27 5:32 ` Benjamin Herrenschmidt
2004-02-27 6:26 ` Michael Frank
2004-02-27 6:46 ` Benjamin Herrenschmidt
2004-02-27 9:05 ` Russell King
2004-02-27 13:31 ` Michael Frank
2004-02-27 13:45 ` Richard B. Johnson
2004-02-27 13:50 ` Russell King
2004-02-27 14:51 ` Michael Frank
2004-02-27 7:25 ` Arjan van de Ven
2004-02-27 10:15 ` Helge Hafting
2004-02-27 18:32 ` Mike Fedyk
2004-02-26 23:47 Albert Cahalan
2004-02-26 19:05 Tim Bird
2004-02-26 19:39 ` Richard B. Johnson
2004-02-26 21:02 ` Tim Bird
2004-02-26 21:30 ` Arjan van de Ven
2004-02-26 22:21 ` Mark Gross
2004-02-27 7:14 ` Arjan van de Ven
2004-02-27 11:27 ` Ingo Oeser
2004-02-27 11:52 ` Arjan van de Ven
2004-02-27 13:23 ` Richard B. Johnson
2004-02-27 12:04 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04022714534500.12104@tabby \
--to=jesse@cats-chateau.net \
--cc=andrew.grover@intel.com \
--cc=helgehaf@aitel.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=mhf@linuxmail.org \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox