Messages in this thread | | | Subject | Re: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs | From | "H. Peter Anvin" <> | Date | Wed, 22 Feb 2012 00:01:03 -0800 |
| |
Stupid thought... do we have cases that matter where the bias and default don't agree?
Ingo Molnar <mingo@elte.hu> wrote:
> >* Ingo Molnar <mingo@elte.hu> wrote: > >> But it is fundamentally mixing execution and *data type* and >> it is not conveying the build time bias properly. >> >> So the best high level naming would be something like: >> >> struct static_condition static_flag = STATIC_COND_FALSE; >> >> >> if (very_unlikely(&static_flag)) { >> ... >> } >> >> ... >> >> static_cond_inc(&static_flag); >> ... >> static_cond_dec(&static_flag); > >Btw., I think the modification path could also carry the high >cost of modification (stopping all cpus, modifying code, etc.). > >This could be done via: > > static_cond_slow_inc(&static_flag); > ... > static_cond_slow_dec(&static_flag); > >And if a developer does not notice that 'slow' implies a >performance cost, then he probably would have doubly missed this >aspect of jump_label_inc()/jump_label_dec(). > >Thanks, > > Ingo
-- Sent from my mobile phone. Please excuse my brevity and lack of formatting.
| |