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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFxRF=9xav_XEMizV2vqiX6S4SigBxFTrXwWTRrTKG1Yvw@mail.gmail.com>
Date:   Fri, 12 Jan 2018 09:51:42 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mike Galbraith <efault@....de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Eric Dumazet <edumazet@...gle.com>,
        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 Fri, Jan 12, 2018 at 9:44 AM, Mike Galbraith <efault@....de> wrote:
>
> Nah, a misunderstanding happened.  RT that still offers full threading
> creates per-softirq threads per cpu.  The regular trees split ksoftirqd
> into only two threads per cpu, one processes timer/hrtimer softriqs,
> the other processes the rest.

Ok, that sounds like it should work, but it also sounds like it's very
specific to RT itself.

For example, the dvb issue was not about the timer softirqs, but about
the tasklet ones.

So maybe we wouldn't need to split it for _every_ softirq, but we'd
need to split it more than just along the timer case.

And it does sound a bit excessive to have ten fixed threads for every
CPU. The days when tens of CPU's meant "huge system" are gone. These
days it can be a phone.

            Linus