lkml.org 
[lkml]   [2011]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2011-02-11 23:19    [W:4.122 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site