lkml.org 
[lkml]   [2018]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 29/30] softirq: Make softirq processing softinterruptible
    Hi Frederic,

    On Wed, Oct 17, 2018 at 02:26:02AM +0200, Frederic Weisbecker wrote:
    > Hi Pavan,
    >
    > On Tue, Oct 16, 2018 at 09:45:52AM +0530, Pavan Kondeti wrote:
    > > Hi Frederic,
    > >
    > > On Thu, Oct 11, 2018 at 01:12:16AM +0200, Frederic Weisbecker wrote:
    > > > From: Frederic Weisbecker <fweisbec@gmail.com>
    > > >
    > > > Make do_softirq() re-entrant and allow a vector, being either processed
    > > > or disabled, to be interrupted by another vector. This way a vector
    > > > won't be able to monopolize the CPU for a long while at the expense of
    > > > the others that may rely on some predictable latency, especially on
    > > > softirq disabled sections that used to disable all vectors.
    > > >
    > > I understand that a long running softirq can be preempted/interrupted by
    > > other softirqs which is not possible today. I have few questions on your
    > > patches.
    > >
    > > (1) When softirq processing is pushed to ksoftirqd, then the long running
    > > softirq can still block other softirqs (not in SOFTIRQ_NOW_MASK) for a while.
    > > correct?
    >
    > No, Ksoftirqd is treated the same as IRQ tail processing here: a vector can
    > interrupt another. So for example, a NET_RX softirq running in Ksoftirqd can
    > be interrupted by a TIMER softirq running in hardirq tail.
    >
    When ksoftirqd is running, we are only allowing softirqs in SOFTIRQ_NOW_MASK
    to run after serving an interrupt. So I don't see how TIMER which is not
    in SOFTIRQ_NOW_MASK can interrupt a NET_RX softirq running in ksoftirqd
    context.

    > >
    > > (2) When softirqs processing happens asynchronously, a particular softirq
    > > like TASKLET can keep interrupting an already running softirq like TIMER/NET_RX,
    > > correct? In worse case scenario, a long running softirq like NET_RX interrupt
    > > a TIMER softirq. But I guess this is something expected with this. i.e
    > > each softirq is independent and whichever comes recent gets to interrupt the
    > > previously running softirqs.
    >
    > Exactly, and that's inherent with interrupts in general. The only way to work
    > around that is to thread each vector independantly but that's a whole different
    > dimension :-)
    >
    Right.

    Assigning a thread for each vector also may not solve this problem because
    preemption would be disabled while a softirq vector is running in its own
    thread.

    I guess there is no hard priorities among softirq vectors. Earlier
    it was like first come first serve, now it is not. If we had priorities
    defined, (don't know how :-)) we could disable the lower prio vectors while a
    higher prio vector is being handled. This way we could gaurantee that TIMER
    softirq or HI-TASKLET won't be starved while a long running softirq like
    NET_RX/NET_TX/RCU is running.

    Thanks,
    Pavan
    --
    Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
    Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

    \
     
     \ /
      Last update: 2018-10-22 10:12    [W:6.423 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site