linux-kernel - Re: [PATCH net-next v6 2/7] net: Suspend softirq when prefer_busy

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: <20241107195203.72ea09b9@kernel.org>
Date: Thu, 7 Nov 2024 19:52:03 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Joe Damato <jdamato@...tly.com>
Cc: netdev@...r.kernel.org, corbet@....net, hdanton@...a.com,
 bagasdotme@...il.com, pabeni@...hat.com, namangulati@...gle.com,
 edumazet@...gle.com, amritha.nambiar@...el.com,
 sridhar.samudrala@...el.com, sdf@...ichev.me, peter@...eblog.net,
 m2shafiei@...terloo.ca, bjorn@...osinc.com, hch@...radead.org,
 willy@...radead.org, willemdebruijn.kernel@...il.com, skhawaja@...gle.com,
 Martin Karsten <mkarsten@...terloo.ca>, "David S. Miller"
 <davem@...emloft.net>, Simon Horman <horms@...nel.org>, David Ahern
 <dsahern@...nel.org>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Lorenzo Bianconi <lorenzo@...nel.org>, Alexander Lobakin
 <aleksander.lobakin@...el.com>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v6 2/7] net: Suspend softirq when
 prefer_busy_poll is set

On Wed, 6 Nov 2024 19:24:32 -0800 Joe Damato wrote:
> > In your case, when machine is not melting under 100% load - prefer busy
> > poll will be set once or not at all.  
> 
> I am not sure what you mean by that last sentence, because the
> prefer busy poll flag is set by the application?

There are two flags with almost exactly the same name, that's probably
the source of misunderstanding. NAPI_F_PREFER_BUSY_POLL will always be
set, but unless we are actually in a "napi live lock"
NAPI_STATE_PREFER_BUSY_POLL will not get set, and the latter is what
napi_prefer_busy_poll() tests. But we're dropping this patch so
doesn't matter. I was trying to pile up reasons why checking
napi_prefer_busy_poll() should not be necessary.

> Similar to prefer busy poll piggybacking on IRQ deferral, we
> piggyback on prefer busy polling by allowing the application to use
> an even larger timeout while it is processing incoming data, i.e.,
> deferring IRQs for a longer period, but only after a successful busy
> poll. This makes prefer busy poll + irq suspend useful when
> utilization is below 100%.
> 
> > > The overall point to make is that: the suspend timer is used to
> > > prevent misbehaving userland applications from taking too long. It's
> > > essentially a backstop and, as long as the app is making forward
> > > progress, allows the app to continue running its busy poll loop
> > > undisturbed (via napi_complete_done preventing the driver from
> > > enabling IRQs).
> > > 
> > > Does that make sense?  
> > 
> > My mental model put in yet another way is that only epoll knows if it
> > has events, and therefore whether the timeout should be short or long.
> > So the suspend timer should only be applied by epoll.  
> 
> Here's what we are thinking, can you let me know if you agree with
> this?
> 
>   - We can drop patch 2 entirely
>   - Update the documentation about IRQ suspension as needed now
>     that patch 2 has been dropped
>   - Leave the rest of the series as is
>   - Re-run our tests to gather sufficient data for the test cases
>     outlined in the cover letter to ensure that the performance
>     numbers hold over several iterations
> 
> Does that seem reasonable for the v7 to you?
> 
> I am asking because generating the amount of data over the number of
> scenarios we are testing takes a long time and I want to make sure
> we are as aligned as we can be before I kick off another run :)

SGTM, the rest of the series makes perfect sense to me.
Sorry for the delay..