[lkml]   [2006]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Profile likely/unlikely macros
    On Wed, 26 April 2006 11:08:09 +1000, Nick Piggin wrote:
    > Daniel Walker wrote:
    > Ah, I see. Then you should be OK with either your current scheme, or
    > Andrew's suggestion, so long as you have a memory barrier before the
    > unlock (eg. smp_mb__before_clear_bit()).
    > >I'm not exactly sure what you mean by "release consistency" ?
    > Without a barrier, the stores to the linked list may be visible to another
    > CPU after the store that unlocks the atomic_t. Ie. the critical section can
    > leak out of the lock.

    Admitted, I'm a bit slow at times. But why does this matter?
    According to my fairly limited brain, you take a potentially expensive
    barrier, so you pay with a bit of runtime. What you buy is a smaller
    critical section, so you can save some runtime on other cpus. When
    optimizing for the common case, which is one cpu, this is a net loss.

    There must be some correctness issue hidden that I cannot see. Can
    you explain that to me?


    A victorious army first wins and then seeks battle.
    -- Sun Tzu
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-26 11:59    [W:0.021 / U:56.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site