public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Robert_Hentosh@Dell.com, linux-kernel@vger.kernel.org
Subject: Re: spurious 8259A interrupt
Date: Fri, 19 Mar 2004 13:39:42 +0000	[thread overview]
Message-ID: <20040319133942.GA3897@mail.shareable.org> (raw)
In-Reply-To: <20040319131608.A14431@flint.arm.linux.org.uk>

Russell King wrote:
> Interrupt handlers generally run with the CPU interrupt disable flag
> cleared, so other interrupts can be serviced.

Indeed.  But why?  What's the advantage?

The obvious thought is it might improve latency of interrupt handlers
which need reasonably low latency, when other handlers take a long time.

E.g. if the irq 1 handler takes a long time, multiple irq 2
interrupts can be serviced during it.

But that doesn't work, when there are no meaningful hardware
priorities: an irq 2 handler can be interrupted by the long irq 1
handler, maybe before it gets to do anything useful, and then the irq
2 interrupt doesn't have low latency.

(I gather that irq priorities aren't especially meaningful on the x86
platform, as brought up on another thread recently).

Perhaps it works out statistically better.

Can you confirm that it does work out statistically better, or that
there's something I didn't think of?

Thanks,
-- Jamie

  reply	other threads:[~2004-03-19 13:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16 20:32 spurious 8259A interrupt Robert_Hentosh
2004-03-19 13:06 ` Jamie Lokier
2004-03-19 13:16   ` Russell King
2004-03-19 13:39     ` Jamie Lokier [this message]
2004-03-19 14:04       ` Anton Blanchard
2004-03-19 14:56         ` Jamie Lokier
2004-03-19 13:48   ` Richard B. Johnson
2004-03-19 14:39     ` Jamie Lokier
2004-03-21 17:58     ` Hans-Peter Jansen
2004-03-22  9:12       ` Maciej W. Rozycki
2004-03-22 12:29       ` Richard B. Johnson
2004-03-24 15:28         ` Jamie Lokier
2004-03-24 15:50           ` Gabriel Paubert
2004-03-24 15:57           ` Richard B. Johnson
2004-03-19 13:28 ` Maciej W. Rozycki
2004-03-19 22:01   ` Guennadi Liakhovetski
2004-03-22  9:02     ` Maciej W. Rozycki
2004-03-22 21:16       ` Guennadi Liakhovetski
2004-03-22 22:13         ` Richard B. Johnson
2004-03-22 23:09           ` Guennadi Liakhovetski
2004-03-22 23:38             ` Richard B. Johnson
2004-03-23 10:32               ` Maciej W. Rozycki
2004-03-23 10:42             ` Maciej W. Rozycki
2004-03-23 21:10               ` Guennadi Liakhovetski
2004-03-23 10:29           ` Maciej W. Rozycki
2004-03-23 10:26         ` Maciej W. Rozycki
  -- strict thread matches above, loose matches on Subject: below --
2004-03-16 18:35 Emmanuel Fleury

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=20040319133942.GA3897@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=Robert_Hentosh@Dell.com \
    --cc=linux-kernel@vger.kernel.org \
    /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