linux-kernel - Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iJzekwx_Hs0t0O==+gwAfqMyVHBg=gemayZZJXb4bYJdQ@mail.gmail.com>
Date:   Thu, 11 Jan 2018 11:48:26 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Dmitry Safonov <dima@...sta.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Miller <davem@...emloft.net>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Ingo Molnar <mingo@...nel.org>,
        "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>,
        Paolo Abeni <pabeni@...hat.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Radu Rendec <rrendec@...sta.com>,
        Rik van Riel <riel@...hat.com>,
        Stanislaw Gruszka <sgruszka@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, Jan 11, 2018 at 11:43 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Jan 11, 2018 at 11:15 AM, Eric Dumazet <edumazet@...gle.com> wrote:
>>
>> How are we supposed to know this particular workload is problematic
>> for innocent user threads on the same cpu ?
>
> Put that question another way: how is the _softirq_ code supposed to know?

That was the purpose on the last patch : As soon as ksoftirqd is scheduled
(by some kind of jitter in the 99,000 pps workload, or antagonist wakeup),
we then switch to a mode where process scheduler can make decisions
based on threads prios and cpu usage.

Then, as soon as the load was able to finish in its quantum the
pending irqs, we re-enter the mode
where softirq are immediately serviced.

>
> If you can't know, then the softirq code definitely can't know either.
> It has even less information. It doesn't know about NAPI, it doesn't
> know about irq steering, it doesn't know anything at all.

That is true.