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]

Date:   Fri, 12 Jan 2018 09:24:14 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mike Galbraith <efault@....de>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        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 9:23 PM, Mike Galbraith <efault@....de> wrote:
> On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote:
>>
>> So maybe we could get rid of the per-cpu ksoftirqd entirely, and
>> replace it with with per-cpu and per-softirq workqueues?
>
> How would that be better than what RT used to do, and I still do for my
> RT kernels via boot option, namely split ksoftirqd into per-softirq
> threads.

So I think testing and playing around with things is probably the way
to go, but the  reason I would suggest at least looking at workqueues
is that I feel that we already have a *ton* of percpu threads, and
multiplying the ksoftirqd threads by a factor of ten (or however many
softirqs we have) sounds insane.

And yes, they do need to be percpu. Networking wants to do all that
packet handling concurrently across CPUs, so we can't just replace the
per-cpu ksoftirqd threads with per-softirq threads: we really do want
both per-cpu _and_ per-softirq.

And honestly, that sounds insane to do with dedicated threads, most of
which do basically nothing at all.. And it's what the workqueue
threads are designed for - expanding as needed, and not tying up a
dedicated thread for every little work.

But code and testing talks,

            Linus