[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
    On Mon, 2011-02-14 at 13:46 -0800, David Miller wrote:
    > From: Steven Rostedt <>
    > Date: Mon, 14 Feb 2011 16:39:36 -0500
    > > Thus it is not about global, as global is updated by normal means and
    > > will update the caches. atomic_t is updated via the ll/sc that ignores
    > > the cache and causes all this to break down. IOW... broken hardware ;)
    > I don't see how cache coherency can possibly work if the hardware
    > behaves this way.
    > In cache aliasing situations, yes I can understand a L1 cache visibility
    > issue being present, but with kernel only stuff that should never happen
    > otherwise we have a bug in the arch cache flushing support.

    I guess the issue is, if you use ll/sc on memory, you must always use
    ll/sc on that memory, otherwise any normal read won't read the proper

    The atomic_read() in this arch uses ll to read the memory directly and
    skip the cache. If we make atomic_read() like the other archs:

    #define atomic_read(v) (*(volatile int *)&(v)->counter)

    This pulls the counter into cache, and it will not be updated by a
    atomic_inc() from another CPU.

    Ideally, we would like a single atomic_read() but due to these wacky
    archs, it may not be possible.

    -- Steve

     \ /
      Last update: 2011-02-14 23:23    [W:0.026 / U:150.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site