lkml.org 
[lkml]   [2011]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/2] jump label: 2.6.38 updates
    From
    Date
    On Mon, 2011-02-14 at 17:50 +0000, Will Newton wrote:
    > On Mon, Feb 14, 2011 at 5:43 PM, Peter Zijlstra <peterz@infradead.org> wrote:
    > > On Mon, 2011-02-14 at 17:38 +0000, Will Newton wrote:
    > >> On Mon, Feb 14, 2011 at 5:27 PM, Peter Zijlstra <peterz@infradead.org> wrote:
    > >>
    > >> >> So all but a few have basically (as you said on IRC)
    > >> >> #define atomic_read(v) ACCESS_ONCE(v)
    > >> >
    > >> > ACCESS_ONCE(v->counter), but yeah :-)
    > >>
    > >> I maintain an out-of-tree architecture where that isn't the case
    > >> unfortunately [1]. Not expecting any special favours for being
    > >> out-of-tree of course, but just thought I would add that data point.
    > >>
    > >> [1] Our atomic operations go around the cache rather than through it,
    > >> so the value of an atomic cannot be read with a normal load
    > >> instruction.
    > >
    > > Cannot how? It would observe a stale value? That is acceptable for
    > > atomic_read().
    >
    > It would observe a stale value, but that value would only be updated
    > when the cache line was reloaded from main memory which would have to
    > be triggered by either eviction or cache flushing. So it could get
    > pretty stale. Whilst that's probably within the spec. of atomic_read I
    > suspect it would lead to problems in practice. I could be wrong
    > though.

    Arguable, finding such cases would be a Good (TM) thing.. but yeah, I
    can imagine you're not too keen on being the one finding them.

    Luckily it looks like you're in the same boat as blackfin-smp is.



    \
     
     \ /
      Last update: 2011-02-14 19:05    [W:0.023 / U:3.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site