Messages in this thread | | | Date | Fri, 11 Feb 2011 17:15:50 -0500 | From | Jason Baron <> | Subject | Re: [PATCH 0/2] jump label: 2.6.38 updates |
| |
On Fri, Feb 11, 2011 at 10:38:17PM +0100, Peter Zijlstra wrote: > On Fri, 2011-02-11 at 16:13 -0500, Mathieu Desnoyers wrote: > > > > Thoughts ? > > #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) > + > +struct jump_label_key { > + void *ptr; > +}; > > struct jump_label_entry { > struct hlist_node hlist; > struct jump_entry *table; > - int nr_entries; > /* hang modules off here */ > struct hlist_head modules; > unsigned long key; > + u32 nr_entries; > + int refcount; > }; > > #else > > +struct jump_label_key { > + int state; > +}; > > #endif > > > > So why can't we make that jump_label_entry::refcount and > jump_label_key::state an atomic_t and be done with it? > > Then the enabled case uses if (atomic_inc_return(&key->ptr->refcount) == > 1), and the disabled atomic_inc(&key->state). >
a bit of history...
For the disabled jump label case, we didn't want to incur an atomic_read() to check if the branch was enabled.
So, I separated the API, to have one for the non-atomic case, and one for the atomic case. Nobody liked that.
So now, I'm proposing to leave the core API based around a non-atomic variable, and have any callers that want to use this atomic interface, to call into the non-atomic interface. If another user besides perf wants to use the same type of atomic interface, we can re-visit the decsion?
thanks,
-Jason
| |