[lkml]   [2009]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH -tip] x86: do_IRQ - send EOI for x86-32 on irq without handler v2
[Ingo Molnar - Wed, Apr 08, 2009 at 04:52:18PM +0200]
| * Cyrill Gorcunov <> 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)
* 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);

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


 \ /
  Last update: 2009-04-08 17:49    [W:0.036 / U:5.124 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site