Thread (116 messages) 116 messages, 11 authors, 2017-07-10

Re: [PATCH v2 0/9] Remove spin_unlock_wait()

From: Paul E. McKenney <hidden>
Date: 2017-07-08 11:41:21
Also in: linux-arch, lkml, netfilter-devel

On Sat, Jul 08, 2017 at 10:43:24AM +0200, Ingo Molnar wrote:
* Paul E. McKenney [off-list ref] wrote:
quoted
On Fri, Jul 07, 2017 at 10:31:28AM +0200, Ingo Molnar wrote:

[ . . . ]
quoted
In fact I'd argue that any future high performance spin_unlock_wait() user is 
probably better off open coding the unlock-wait poll loop (and possibly thinking 
hard about eliminating it altogether). If such patterns pop up in the kernel we 
can think about consolidating them into a single read-only primitive again.
I would like any reintroduction to include a header comment saying exactly
what the consolidated primitive actually does and does not do.  ;-)
quoted
I.e. I think the proposed changes are doing no harm, and the unavailability of a 
generic primitive does not hinder future optimizations either in any significant 
fashion.
I will have a v3 with updated comments from Manfred.  Thoughts on when/where
to push this?
Once everyone agrees I can apply it to the locking tree. I think PeterZ's was the 
only objection?
Oleg wasn't all that happy, either, but he did supply the relevant patch.
quoted
The reason I ask is if this does not go in during this merge window, I need
to fix the header comment on spin_unlock_wait().
Can try it next week after some testing - let's see how busy things get for Linus 
in the merge window?
Sounds good!  Either way is fine with me.

							Thanx, Paul
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help