linux-kernel - Re: [RFC net-next 0/5] Suspend IRQs during preferred busy poll

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] [day] [month] [year] [list]

Message-ID: <3c7543a5-891b-4aa8-b6d5-32afb6835035@uwaterloo.ca>
Date: Tue, 20 Aug 2024 10:28:29 -0400
From: Martin Karsten <mkarsten@...terloo.ca>
To: Jakub Kicinski <kuba@...nel.org>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 Joe Damato <jdamato@...tly.com>
Cc: Samiullah Khawaja <skhawaja@...gle.com>,
 Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
 amritha.nambiar@...el.com, sridhar.samudrala@...el.com,
 Alexander Lobakin <aleksander.lobakin@...el.com>,
 Alexander Viro <viro@...iv.linux.org.uk>, Breno Leitao <leitao@...ian.org>,
 Christian Brauner <brauner@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jan Kara <jack@...e.cz>, Jiri Pirko <jiri@...nulli.us>,
 Johannes Berg <johannes.berg@...el.com>, Jonathan Corbet <corbet@....net>,
 "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
 "open list:FILESYSTEMS (VFS and infrastructure)"
 <linux-fsdevel@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 Lorenzo Bianconi <lorenzo@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [RFC net-next 0/5] Suspend IRQs during preferred busy poll

On 2024-08-19 22:36, Jakub Kicinski wrote:
> On Sun, 18 Aug 2024 10:51:04 -0400 Martin Karsten wrote:
>>>> I believe this would take away flexibility without gaining much. You'd
>>>> still want some sort of admin-controlled 'enable' flag, so you'd still
>>>> need some kind of parameter.
>>>>
>>>> When using our scheme, the factor between gro_flush_timeout and
>>>> irq_suspend_timeout should *roughly* correspond to the maximum batch
>>>> size that an application would process in one go (orders of magnitude,
>>>> see above). This determines both the target application's worst-case
>>>> latency as well as the worst-case latency of concurrent applications, if
>>>> any, as mentioned previously.
>>>
>>> Oh is concurrent applications the argument against a very high
>>> timeout?
>>
>> Only in the error case. If suspend_irq_timeout is large enough as you
>> point out above, then as long as the target application behaves well,
>> its batching settings are the determining factor.
> 
> Since the discussion is still sort of going on let me ask something
> potentially stupid (I haven't read the paper, yet). Are the cores
> assumed to be fully isolated (ergo the application can only yield
> to the idle thread)? Do we not have to worry about the scheduler
> deciding to schedule the process out involuntarily?

That shouldn't be a problem. If the next thread(s) can make progress, 
nothing is lost. If the next thread(s) cannot make progress, for example 
waiting for network I/O, they will block and the target application 
thread will run again. If another thread is busy-looping on network I/O, 
I would argue that having multiple busy-looping threads competing for 
the same core is probably not a good idea anyway.

Thanks,
Martin