From: Anton Blanchard <anton@samba.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Robert_Hentosh@Dell.com, linux-kernel@vger.kernel.org
Subject: Re: spurious 8259A interrupt
Date: Sat, 20 Mar 2004 01:04:55 +1100 [thread overview]
Message-ID: <20040319140455.GB1153@krispykreme> (raw)
In-Reply-To: <20040319133942.GA3897@mail.shareable.org>
> Indeed. But why? What's the advantage?
We enable IRQs during IRQ processing on ppc64 for one reason. We set the
IPI priority higher than normal IRQs so we can service it as soon as
possible and the calling cpu can move on.
> 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.
Yeah. We have a huge number of possible priorities on some ppc64
interrupt controllers but it turns out we dont have a concept of
priority or tolerance of latency for devices in Linux. I could see us
wanting serial IRQs to have a higher priority than disk IRQs if the
information was there for us to exploit.
In the end we map all IRQs to the same priority on ppc64 which means we
will never take a recursive IRQ due to devices.
Anton
next prev parent reply other threads:[~2004-03-19 14:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 20:32 Robert_Hentosh
2004-03-19 13:06 ` Jamie Lokier
2004-03-19 13:16 ` Russell King
2004-03-19 13:39 ` Jamie Lokier
2004-03-19 14:04 ` Anton Blanchard [this message]
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=20040319140455.GB1153@krispykreme \
--to=anton@samba.org \
--cc=Robert_Hentosh@Dell.com \
--cc=jamie@shareable.org \
--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
all inboxes | Powered by JetHome®