[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
    * Steven Rostedt ( wrote:
    > Actually, I was partly under the impression that we didn't care if it
    > was in the fast path. Maybe we need three versions. Let me explain.
    > We have cases where we want it default disabled and the code called when
    > enabled should be as out of line as possible. Tracing definitely falls
    > in this pattern. But we could push a "unlikely(static_branch())" for
    > such a case (or keep it as very_unlikely()).
    > Then we have cases where it is default enabled, where we can insert the
    > code in the fast path. Or do we even care how the compiler places it?
    > Because this leads us to the third use...
    > The third use is the case were we don't know the branch should be taken
    > or not until boot. We don't want the compiler to optimize the paths at
    > all. This example is for things like CPU features or types (as HPA
    > explained the "if (very_unlikely(cpu_vendor_amd))". This is the category
    > that we want to have an efficient system for the running hardware. We
    > can't bias one way or the other at compile time because frankly, we
    > don't know the answer until run time. This could also be used by modules
    > that are drivers for several types of hardware, and it can dynamically
    > change itself to suit the hardware it is driving.
    One possible naming that might be a good fit:

    - read_always_likely()
    - read_always_unlikely()
    - read_always_branch()

    I think it is important to convey both that it is expected to be always
    read, pretty much never updated, and the bias, or absence of bias.

    I also _like_ to have a relatively long name here, because the update
    cost is so high that someone should really think before using this
    facility. In my opinion, it's not "just" a stronger likely/unlikely.

    Thoughts ?



    Mathieu Desnoyers
    Operating System Efficiency R&D Consultant
    EfficiOS Inc.

     \ /
      Last update: 2012-02-22 15:23    [W:0.028 / U:1.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site