> On Jul 28, 2015, at 21:21, Peter Zijlstra <[email protected]> wrote: > > There are various problems and short-comings with the current > static_key interface: > > - static_key_{true,false}() read like a branch depending on the key > value, instead of the actual likely/unlikely branch depending on > init value. > > - static_key_{true,false}() are, as stated above, tied to the > static_key init values STATIC_KEY_INIT_{TRUE,FALSE}. > > - we're limited to the 2 (out of 4) possible options that compile to > a default NOP because that's what our arch_static_branch() assembly > emits. > > So provide a new static_key interface: > > DEFINE_STATIC_KEY_TRUE(name); > DEFINE_STATIC_KEY_FALSE(name); > > Which define a key of different types with an initial true/false > value. > > Then allow: > > static_branch_likely() > static_branch_unlikely() > > to take a key of either type and emit the right instruction for the > case. > > This means adding a second arch_static_branch_jump() assembly helper > which emits a JMP per default. > > In order to determine the right instruction for the right state, > encode the branch type in the LSB of jump_entry::key. > > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > --- > is this means static_key_{true,false}() are deprecated ? do you need mark static_key_{true,false}() as deprecated? like this: static __always_inline __deprecated bool static_key_false(struct static_key *key) ? Thanks
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
