From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jesse Barnes <jesse.barnes@intel.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andreas Schwab <schwab@suse.de>, Len Brown <lenb@kernel.org>
Subject: Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early)
Date: Tue, 3 Feb 2009 11:38:16 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0902031120080.3247@localhost.localdomain> (raw)
In-Reply-To: <20090203191334.GA2797@elte.hu>
On Tue, 3 Feb 2009, Ingo Molnar wrote:
> >
> > I'm really not sure why that handle_edge_irq thing uses "ack_and_mask()"
> > instead of just "desc->chip->ack()"? I'm also totally flummoxed as to why
> > it feels it needs to go all the way out to the device to mask things,
> > instead of just masking at an apic level, which is much simpler and faster
> > (especially since masking should never happen in practice anyway).
>
> Hm, do you mean mask_ack_irq()?
Yes.
> The ->mask_ack() irqchip method is just a
> small tweak normally: if we get an irq while the irq was disabled, we can
> mark it pending and masks it for real.
No, I know why mask_ack_irq() does what it does and I agree with it. What
I was really reacting to was that handle_edge_irq() calls it at _all_.
IOW, I'm talking about this code:
handle_edge_irq(unsigned int irq, struct irq_desc *desc)
...
if (unlikely((desc->status & (IRQ_INPROGRESS | IRQ_DISABLED)) ||
!desc->action)) {
desc->status |= (IRQ_PENDING | IRQ_MASKED);
mask_ack_irq(desc, irq);
..
where the masking part seems a bit pointless. And in the case of MSI, it
causes us to go all the way out to the device, which sounds pretty
expensive too.
So if you have high enough interrupt load that you get another interrupt
on another CPU while handling one, I think the "mask_ack_irq()" likely
makes things go slower. It also causes us to have that horrible:
/*
* When another irq arrived while we were handling
* one, we could have masked the irq.
* Renable it, if it was not disabled in meantime.
*/
if (unlikely((desc->status &
(IRQ_PENDING | IRQ_MASKED | IRQ_DISABLED)) ==
(IRQ_PENDING | IRQ_MASKED))) {
desc->chip->unmask(irq);
desc->status &= ~IRQ_MASKED;
}
code there in the middle of the loop to handle the interrupt.
That function has another oddity too: it does
if (unlikely(!action)) {
desc->chip->mask(irq);
goto out_unlock;
}
but the thing is, if somebody unregistered the interrupt, then it should
have been masked to begin with. Why would be need to mask it in the
interrupt handler?
Maybe I'm missing something really subtle, but my reaction would be that
the function _should_ look just something like the appended.
But no, I'm really not going to commit this. Consider this patch to be a
question ("why does it do that?") rather than a suggestion ("we should do
this").
Linus
---
kernel/irq/chip.c | 20 +++-----------------
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 7de11bd..ad852ce 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -468,8 +468,8 @@ handle_edge_irq(unsigned int irq, struct irq_desc *desc)
*/
if (unlikely((desc->status & (IRQ_INPROGRESS | IRQ_DISABLED)) ||
!desc->action)) {
- desc->status |= (IRQ_PENDING | IRQ_MASKED);
- mask_ack_irq(desc, irq);
+ desc->status |= IRQ_PENDING;
+ desc->chip->ack(irq);
desc = irq_remap_to_desc(irq, desc);
goto out_unlock;
}
@@ -486,22 +486,8 @@ handle_edge_irq(unsigned int irq, struct irq_desc *desc)
struct irqaction *action = desc->action;
irqreturn_t action_ret;
- if (unlikely(!action)) {
- desc->chip->mask(irq);
+ if (unlikely(!action))
goto out_unlock;
- }
-
- /*
- * When another irq arrived while we were handling
- * one, we could have masked the irq.
- * Renable it, if it was not disabled in meantime.
- */
- if (unlikely((desc->status &
- (IRQ_PENDING | IRQ_MASKED | IRQ_DISABLED)) ==
- (IRQ_PENDING | IRQ_MASKED))) {
- desc->chip->unmask(irq);
- desc->status &= ~IRQ_MASKED;
- }
desc->status &= ~IRQ_PENDING;
spin_unlock(&desc->lock);
next prev parent reply other threads:[~2009-02-03 19:39 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200901261904.n0QJ4Q9c016709@hera.kernel.org>
2009-02-02 9:54 ` PCI PM: Restore standard config registers of all devices early Benjamin Herrenschmidt
2009-02-02 17:06 ` Linus Torvalds
2009-02-02 20:29 ` Benjamin Herrenschmidt
2009-02-02 20:41 ` Linus Torvalds
2009-02-02 21:00 ` Benjamin Herrenschmidt
2009-02-02 21:32 ` Rafael J. Wysocki
2009-02-02 20:33 ` Benjamin Herrenschmidt
2009-02-02 20:50 ` Linus Torvalds
2009-02-02 20:55 ` Linus Torvalds
2009-02-02 21:19 ` Benjamin Herrenschmidt
2009-02-02 21:39 ` Rafael J. Wysocki
2009-02-02 22:05 ` Linus Torvalds
2009-02-02 22:09 ` Linus Torvalds
2009-02-02 22:31 ` Rafael J. Wysocki
2009-02-02 23:18 ` Linus Torvalds
2009-02-02 23:45 ` Rafael J. Wysocki
2009-02-02 23:59 ` Linus Torvalds
2009-02-03 0:15 ` Rafael J. Wysocki
2009-02-03 0:28 ` Linus Torvalds
2009-02-03 1:12 ` Benjamin Herrenschmidt
2009-02-03 1:32 ` Linus Torvalds
2009-02-03 1:46 ` Benjamin Herrenschmidt
2009-02-03 3:30 ` Benjamin Herrenschmidt
2009-02-03 3:47 ` Linus Torvalds
2009-02-03 4:03 ` Benjamin Herrenschmidt
2009-02-03 6:07 ` Benjamin Herrenschmidt
2009-02-03 15:48 ` Linus Torvalds
2009-02-03 22:59 ` Benjamin Herrenschmidt
2009-02-03 23:23 ` Rafael J. Wysocki
2009-02-03 16:33 ` Jesse Barnes
2009-02-03 0:15 ` Linus Torvalds
2009-02-03 0:58 ` Benjamin Herrenschmidt
2009-02-03 3:51 ` Benjamin Herrenschmidt
2009-02-03 3:55 ` Benjamin Herrenschmidt
2009-02-03 4:09 ` Linus Torvalds
2009-02-03 4:21 ` Benjamin Herrenschmidt
2009-02-03 9:26 ` Rafael J. Wysocki
2009-02-03 17:04 ` Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early) Rafael J. Wysocki
2009-02-03 17:59 ` Linus Torvalds
2009-02-03 18:31 ` Linus Torvalds
2009-02-03 18:41 ` Ingo Molnar
2009-02-03 18:32 ` Jesse Barnes
2009-02-03 18:46 ` Linus Torvalds
2009-02-03 19:03 ` Linus Torvalds
2009-02-03 19:13 ` Ingo Molnar
2009-02-03 19:38 ` Linus Torvalds [this message]
2009-02-03 19:53 ` Ingo Molnar
2009-02-03 20:04 ` Ingo Molnar
2009-02-03 20:18 ` Linus Torvalds
2009-02-03 20:57 ` Ingo Molnar
2009-02-03 21:04 ` Ingo Molnar
2009-02-03 21:12 ` Thomas Gleixner
2009-02-04 10:07 ` Russell King
2009-02-03 21:18 ` Linus Torvalds
2009-02-03 19:19 ` Linus Torvalds
2009-02-03 21:11 ` Benjamin Herrenschmidt
2009-02-03 21:53 ` Rafael J. Wysocki
2009-02-03 22:33 ` Benjamin Herrenschmidt
2009-02-03 22:44 ` Rafael J. Wysocki
2009-02-03 23:05 ` Benjamin Herrenschmidt
2009-02-03 23:18 ` Linus Torvalds
2009-02-04 0:27 ` Benjamin Herrenschmidt
2009-03-04 8:02 ` Pavel Machek
2009-03-04 23:25 ` Benjamin Herrenschmidt
2009-03-05 8:19 ` Pavel Machek
2009-03-05 19:09 ` Rafael J. Wysocki
2009-02-03 23:25 ` Rafael J. Wysocki
2009-02-04 0:46 ` Linus Torvalds
2009-02-03 21:02 ` Benjamin Herrenschmidt
2009-02-03 21:56 ` Rafael J. Wysocki
2009-02-03 17:53 ` PCI PM: Restore standard config registers of all devices early Linus Torvalds
2009-02-03 21:57 ` Rafael J. Wysocki
2009-02-02 22:48 ` Benjamin Herrenschmidt
2009-02-02 23:00 ` Rafael J. Wysocki
2009-02-03 0:23 ` Benjamin Herrenschmidt
2009-02-03 0:29 ` Rafael J. Wysocki
2009-02-03 0:44 ` Linus Torvalds
2009-02-03 1:32 ` Benjamin Herrenschmidt
2009-02-03 5:06 ` Ingo Molnar
2009-02-03 11:06 ` Peter Zijlstra
2009-02-03 12:09 ` Ingo Molnar
2009-02-02 23:49 ` Ingo Molnar
2009-02-03 22:09 ` Rafael J. Wysocki
2009-02-03 23:13 ` Linus Torvalds
2009-02-02 22:28 ` Benjamin Herrenschmidt
2009-02-02 21:07 ` Benjamin Herrenschmidt
2009-02-02 21:49 ` Rafael J. Wysocki
2009-02-02 22:15 ` Linus Torvalds
2009-02-02 22:33 ` Rafael J. Wysocki
2009-02-02 22:56 ` Rafael J. Wysocki
2009-02-03 0:11 ` Benjamin Herrenschmidt
2009-02-03 0:21 ` Linus Torvalds
2009-02-10 20:25 ` Pavel Machek
2009-02-02 22:57 ` Benjamin Herrenschmidt
2009-02-02 23:22 ` Rafael J. Wysocki
2009-02-03 1:03 ` Benjamin Herrenschmidt
2009-02-10 20:25 ` kmalloc during suspend, was " Pavel Machek
2009-02-02 17:20 ` Rafael J. Wysocki
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=alpine.LFD.2.00.0902031120080.3247@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=jesse.barnes@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=schwab@suse.de \
/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
Powered by JetHome