Re: [PATCH] Dynamic tick for x86 version 050602-1

From: Jonathan Corbet (corbet_at_lwn.net)
Date: 06/07/05

  • Next message: Arjan van de Ven: "Re: [RFC PATCH] PCI: remove access to pci_[enable|disable]_msi() for drivers"
    To: Tony Lindgren <tony@atomide.com>
    Date:	Tue, 07 Jun 2005 14:36:14 -0600
    
    

    Tony Lindgren <tony@atomide.com> wrote:

    > --- linux-dev.orig/arch/i386/kernel/irq.c 2005-06-01 17:51:36.000000000 -0700
    > +++ linux-dev/arch/i386/kernel/irq.c 2005-06-01 17:54:32.000000000 -0700
    > [...]
    > @@ -102,6 +103,12 @@ fastcall unsigned int do_IRQ(struct pt_r
    > );
    > } else
    > #endif
    > +
    > +#ifdef CONFIG_NO_IDLE_HZ
    > + if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING) && irq != 0)
    > + dyn_tick->interrupt(irq, NULL, regs);
    > +#endif
    > +
    > __do_IRQ(irq, regs);

    Forgive me if I'm being obtuse (again...), but this hunk doesn't look
    like it would work well in the 4K stacks case. When 4K stacks are being
    used, dyn_tick->interrupt() will only get called in the nested interrupt
    case, when the interrupt stack is already in use. This change also
    pushes the non-assembly __do_IRQ() call out of the else branch, meaning
    that, when the switch is made to the interrupt stack (most of the time),
    __do_IRQ() will be called twice for the same interrupt.

    It looks to me like you want to put your #ifdef chunk *after* the call
    to __do_IRQ(), unless you have some reason for needing it to happen
    before the regular interrupt handler is invoked.

    What am I missing?

    jon

    Jonathan Corbet
    Executive editor, LWN.net
    corbet@lwn.net
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Arjan van de Ven: "Re: [RFC PATCH] PCI: remove access to pci_[enable|disable]_msi() for drivers"

    Relevant Pages

    • Re: IBM: Linux is ready for the Mainframe. SUN: No its not!
      ... So the PSW loaded for type A interrupt would mask type A ... so the type A interrupt handler had time to so some setup ... Of course there were stacks (or ... a hardware interrupt should mask ...
      (comp.unix.solaris)
    • Re: IBM: Linux is ready for the Mainframe. SUN: No its not!
      ... So the PSW loaded for type A interrupt would mask type A ... so the type A interrupt handler had time to so some setup ... Of course there were stacks (or ... a hardware interrupt should mask ...
      (comp.unix.aix)
    • Re: System Hang
      ... "Frank The Tank" wrote: ... An unexpected interrupt (one with an interrupt vector which has no ... You might want to provide the actual stacks. ...
      (microsoft.public.development.device.drivers)
    • Re: Linux-2.6.13-rc6: aic7xxx testers please..
      ... many Windows drivers will need at least 8K size stacks. ... As ndiswrapper seems to be the only option for many wireless chipsets, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Hyper-Threading Vulnerability
      ... a runaway process only gets half the CPU ... I suspected 4k stacks as only change before 'crash' was turning on ... samba server day before, but I didn't trace 'problem' as it wasn't ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)