[lkml]   [2001]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] severe softirq handling performance bug, fix, 2.4.5

    Ingo Molnar writes:
    > (unlike bottom halves, soft-IRQs do not preempt kernel code.)

    Since when do we have this rule? :-)

    > the two error cases are:
    > #1 hard-IRQ interrupts user-space code, activates softirq, and returns to
    > user-space code
    > #2 hard-IRQ interrupts the idle task, activates softirq and returns to
    > the idle task.
    > category #1 is easy to fix, in entry.S we have to check active softirqs
    > not only the exception and ret-from-syscall cases, but also in the
    > IRQ-ret-to-userspace case.
    > category #2 is subtle, because the idle process is kernel code, so
    > returning to it we do not execute active softirqs. The main two types of
    > idle handlers both had a window do 'miss' softirq execution:

    Ingo, I don't think this is the fix.

    You should check Softirqs on return from every single IRQ.
    In do_softirq() it will make sure that we won't run softirqs
    while already doing so or being already nested in a hard-IRQ.

    Every port works this way, I don't know where you got this "soft-IRQs
    cannot run when returning to kernel code" rule, it simply doesn't

    And looking at the x86 code, I don't even understand how your fixes
    can make a difference, what about the do_softirq() call in
    arch/i386/kernel/irq.c:do_IRQ()??? That should be taking care of all
    these "error cases" right?

    David S. Miller
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:54    [W:0.021 / U:8.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site