Messages in this thread | | | Date | Tue, 16 Apr 2019 09:33:15 -0700 | From | Jakub Kicinski <> | Subject | Re: [PATCH 0/3] locking/static_key: improve rate limited labels |
| |
On Thu, 4 Apr 2019 12:29:02 +0200, Peter Zijlstra wrote: > On Mon, Apr 01, 2019 at 11:21:53AM -0700, Jakub Kicinski wrote: > > On Fri, 29 Mar 2019 17:08:51 -0700, Jakub Kicinski wrote: > > > Hi! > > > > > > This will be used to fix the static branch disabling in the TLS > > > code. The net/tls/ code should be using the deferred static > > > branch type, because unprivileged users can flip the branch > > > on and off quite easily with CONFIG_TLS_DEVICE=y. > > > > > > Second of all we shouldn't take the jump label locks from > > > the RX path, when the socket is destroyed. This can be avoided > > > with some slight code refactoring in deferred static_key as > > > it already runs from a workqueue. > > > > > > This the series (and a simple tls patch which makes use of it) > > > applied opening 0.5M TLS connections to localhost (just calling > > > setsockopt, no data exchange) goes down from 37.9s to 12.4s. > > > > Once/if we get positive feedback from locking folks, would it be > > possible to merge these via net-next tree alongside the patch > > converting TLS to rate limited branches? > > Looks good. If routed through the network tree because usage there: > > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> > > Otherwise let me know and I'll carry them.
Hi Peter! I was initially hoping that a1247d06d010 ("locking/static_key: Fix false positive warnings on concurrent dec/inc") may go into 5.1, but it's not really a regression. It will conflict, so the net-next route won't work. Would you be able to carry this set after all?
| |