lkml.org 
[lkml]   [2001]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Re: softirq buggy
    On Mon, Apr 09, 2001 at 05:26:27PM +0200, Manfred Spraul wrote:
    > The return path to user space checks for pending softirqs. A delay of

    And it breaks the loop too if new softirq events become pending again in
    background.

    > 1/HZ is only possible if the cpu loops in kernel space without returning
    > to user space - and the functions that can loop check

    It is also possible when new events are posted and I think it makes
    sense to scale the softirq load with the scheduler when it is flooding.

    Theoretically one could move the _whole_ softirq load into the ksoftirqd, but
    that would increase the latency too much and I think it is better to use it
    only as a fallback when we have to giveup but we still would like to keep
    processing the softirq load so we let the scheduler to choose if we still can
    do that or if we should giveup on the softirq.

    > Is a full thread really necessary? Just setting 'need_resched' should be
    > enough, schedule() checks for pending softirqs.

    If you abuse need_resched then you can starve userspace again, if you are ok
    to starve userspace indefinitely then it is more efficient to keep looping
    forever into do_softirq as far as new events are posted in background instead
    of exiting do_softirq and waiting the scheduler to kickin again.

    > And do you have a rough idea how often that new thread is scheduled
    > under load?

    The scheduling is not as heavy as with tasks, it's a kernel thread
    so the tlb isn't touched. However yes it will generate some overhead
    with schedule() compared to just waiting the 1/HZ but letting the scheduler to
    understand when the softirq should keep running instead of another task is
    supposed to be a feature. I run a netpipe run with an alpha SMP as receiver
    with the ksoftirqd patch and then without and the numbers didn't changed at all
    even if the ksofitrqd was often running (1/2% of the load of the machine).

    > Btw, you don't schedule the ksoftirqd thread if do_softirq() returns
    > from the 'if(in_interrupt())' check.

    That's not necessary and it's intentional, such check will be passed in the
    last do_softirq executed before returning to userspace or kernel normal
    context, the reason of such check is only to avoid recursing too much on the
    stack during nested irqs.

    > I assume that this is the most common case of delayed softirq
    > processing:
    >
    > ; in process context
    > spin_lock_bh();
    > ; hw interrupt arrives
    > ; do_softirq returns immediately
    > spin_unlock_bh();

    This is yet another case and it's handled before returning to userspace so the
    latency should still be pretty small (and there would be no singificant
    advantage and almost certainly only a performance drop in waking up ksoftirqd
    from the `do_softirq returns immediatly' line).

    Andrea
    [unhandled content-type:image/png]
    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:4.626 / U:1.408 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site