linux-kernel - Re: [RFC PATCH 2/4] softirq: Per vector deferment to workqueue

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: <20180209123510.2qxgkky5juejjvcg@linutronix.de>
Date:   Fri, 9 Feb 2018 13:35:10 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Mike Galbraith <efault@....de>
Cc:     Dmitry Safonov <dima@...sta.com>,
        David Miller <davem@...emloft.net>, frederic@...nel.org,
        linux-kernel@...r.kernel.org, alexander.levin@...izon.com,
        peterz@...radead.org, mchehab@...pensource.com,
        torvalds@...ux-foundation.org, hannes@...essinduktion.org,
        paulmck@...ux.vnet.ibm.com, wanpeng.li@...mail.com,
        tglx@...utronix.de, akpm@...ux-foundation.org, pabeni@...hat.com,
        rrendec@...sta.com, mingo@...nel.org, sgruszka@...hat.com,
        riel@...hat.com, edumazet@...gle.com
Subject: Re: [RFC PATCH 2/4] softirq: Per vector deferment to workqueue

On 2018-02-09 05:11:08 [+0100], Mike Galbraith wrote:
> On Thu, 2018-02-08 at 20:30 +0000, Dmitry Safonov wrote:
> > On Thu, 2018-02-08 at 15:22 -0500, David Miller wrote:
> > > Why do we need more than one per cpu?
> > 
> > Ugh, yeah, I remember why I did it - I tried to reuse scheduler for
> > each ksoftirqd thread to decide if it need to run now or later.
> > That would give an admin a way to prioritise softirqs with nice.
> > Not sure if it's a nice idea at all..
> 
> For RT that can be handy, but for the general case it's a waste of
> cycles, so would want to be opt-in.

We used to have it in RT. It got replaced because the context switch from
one thread to the other simply took time.
If you need to prioritise one softirqs over the other I think you would
be better off running with threaded-interrupts. In "normal" mode, if you
have a raised NAPI and say a TASKLET then once both IRQ handler complete
(and interrupts get enabled again) then the softirqs are run. With
threaded interrupts enabled, the NAPI-softirq is invoked once the
threaded-handler completes that raised it - same goes the other threaded
handler which raised the tasklet softirq.
So you could simply change the priority of the threaded interrupt in
order to prefer NAPI over tasklet handling (or the other way around).

> 	-Mike

Sebastian