lkml.org 
[lkml]   [2012]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs
    From
    Date
    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.


    \
     
     \ /
      Last update: 2012-02-22 09:03    [W:0.020 / U:91.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site