Messages in this thread | | | Date | Fri, 17 Dec 2010 16:32:27 -0500 | From | Jason Baron <> | Subject | Re: [PATCH/RFC 1/2] jump label: make enable/disable o(1) |
| |
On Fri, Dec 17, 2010 at 04:12:21PM -0500, Steven Rostedt wrote: > > On 12/17/2010 12:07 PM, Jason Baron wrote: > > > Not acceptable I would think. > > > > How about: > > > > union fubar { > > int key_as_non_atomic; > > atomic_t key_as_atomic; > > }; > > I don't even like this union. > > > > > Now explain the exact semantics of this thing including how you > > guarantee no conflicting accesses *ever* occur. > > I don't like the mixed semantics at all. > > > > > > > > So for when jump labels are disabled case we could have > > > one struct: > > > > > > struct jump_label_key { > > atomic_t state; > > > > } > > > > > > and then we could then have (rough c code): > > > > > > jump_label_enable(struct jump_label_key *key) > > > { > > if (atomic_read(&key->state)) > return; > atomic_inc(&key->state); > > > > } > > > > > > jump_label_disable(struct jump_label_key *key) > > > { > > if (!atomic_read(&key->state)) > return; > atomic_dec(&key->state); > WARN_ON(atomic_read(&key->state); > > > > } > > > > > > jump_label_inc(struct jump_label_key *key) > > > { > > atomic_inc(&key->state) > > > > } > > > > > > jump_label_dec(struct jump_label_key *key) > > > { > > atomic_dec((&key->state) > > > > } > > > > > > bool unlikely_switch(struct jump_label_key *key) > > > { > > if (atomic_read(&key->state)) > > > > return true; > > > return false; > > > } > > > >
hmmm...we were trying to avoid having the atomic_read() for tracepoints b/c of potential extra cost that Mathieu was concerned about.
> There, now you are guaranteed that you have proper semantics. > > > >
The other issue here was that jump_label.h gets included by asm/atomic.h, so there a dependency issue to be addressed here as well....
thanks,
-Jason
| |