From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: [PATCH -tip] x86: do_IRQ - send EOI for x86-32 on irq without handler v2
Date: Wed, 8 Apr 2009 20:21:01 +0400 [thread overview]
Message-ID: <20090408162101.GD7556@lenovo> (raw)
In-Reply-To: <20090408155500.GD3741@elte.hu>
[Ingo Molnar - Wed, Apr 08, 2009 at 05:55:00PM +0200]
|
| * Cyrill Gorcunov <gorcunov@gmail.com> wrote:
|
| > [Ingo Molnar - Wed, Apr 08, 2009 at 04:52:18PM +0200]
| > |
| > | * Cyrill Gorcunov <gorcunov@openvz.org> wrote:
| > |
| > | > Ingo, I think introducing additional dummy here would be a bit
| > | > expencive -- a number of callers of ack_APIC_irq just should not
| > | > check for disable_apic since it's not needed. disable_apic is to
| > | > depend on CONFIG_X86_LOCAL_APIC rather then CONFIG_X86_64
| > | > actually. So make it then. Or you mean something else? Like new
| > | > apic->write_eoi operation? (I'm a bit tired so brain is a half
| > | > functional now :)
| > |
| > | no, i meant a dummy apic->write() method in the !apic case. Check
| > | what ack_APIC_irq() does internally.
| > |
| > | Ingo
| > |
| >
| > Of course I saw how ack_APIC_irq implemented :) It's already guarded
| > by CONFIG_X86_LOCAL_APIC and I could just move check for disable_apic
| > right here (ie it could be like
| >
| > static inline void ack_APIC_irq(void)
| > {
| > #ifdef CONFIG_X86_LOCAL_APIC
| > /*
| > * ack_APIC_irq() actually gets compiled as a single instruction
| > * ... yummie.
| > */
| >
| > if (!disable_apic)
| > /* Docs say use 0 for future compatibility */
| > apic_write(APIC_EOI, 0);
| > #endif
| > }
| >
| > but what is bothering me is that a number of ack_APIC_irq callers
| > will pass execution with always disable_apic=0 and as result
| > this checking would be just spedning cycles for free.
| >
| > So Ingo, it seems I miss something on what you mean. apic->write
| > is already called only for CONFIG_X86_LOCAL_APIC here as well and
| > the arguable point is where to check for disable_apic variable.
| > But do_IRQ is a special case (wrt to say smp_apic_timer_interrupt
| > or setup_local_APIC. I mean as example -- setup_local_APIC is not
| > even called for disable_apic=1).
| >
| > /me: scratching the head heavily
|
| You should look into how apic_write() is implemented. It is a call
| to apic->write().
|
| So my suggestion is that you could implement a freely callable
| ack_APIC_irq() by replacing the apic->write() method with a NOP
| method in the apic-disabled case.
|
| Does that sound good to you?
|
| Ingo
|
Ah, Ingo, now I see what you mean :)
You should only say me like -- implement dynamic apic->write
depending on disabled_apic, now it's clear :-)
Will do.
Cyrill
prev parent reply other threads:[~2009-04-08 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 14:50 [PATCH -tip] x86: do_IRQ - send EOI for x86-32 on irq without handler v2 Cyrill Gorcunov
2009-04-08 14:52 ` Ingo Molnar
2009-04-08 15:45 ` Cyrill Gorcunov
2009-04-08 15:55 ` Ingo Molnar
2009-04-08 16:21 ` Cyrill Gorcunov [this message]
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=20090408162101.GD7556@lenovo \
--to=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.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;
as well as URLs for NNTP newsgroup(s).