Messages in this thread | | | Date | Tue, 2 Jul 2013 11:38:08 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/3] static keys: fix test/set races |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, Jul 01, 2013 at 12:12:11AM -0400, Jason Baron wrote: > > > > Yes, I agree that 'higher' level locking may be required for some callers of > > the newly proposed interface. However, I do think that the > > static_key_slow_set_true()/false() provides a nice abstraction for some > > callers, while addressing test/set() races, by making that sequence atomic. > > > > I view the proposed inteface of set_true()/set_false() as somewhat analogous > > to an atomic_set() call. In the same way, the current > > static_key_slow_inc()/dec() are analogous to atomic_inc()/dec(). > > > > It arguably makes the code code a bit more readable, transforming sequences > > such as: > > > > if (!static_key_enabled(&control_var)) > > static_key_slow_inc(&control_var); > > > > into: > > > > static_key_slow_set_true(&control_var); > > > > > > I see at least 3 users of static_keys in the tree which I think would > > benefit from this transformation. The 2 attached with this series, and the > > usage in kernel/tracepoint.c. > > I tend to agree with Jason here. I also dont' think the scheduler needs > this; but the new API is more usable for binary switches as opposed to > the refcount thing.
Ok - no objections then from me either.
Thanks,
Ingo
| |