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 13:46 -0800, David Miller wrote:
    > From: Steven Rostedt <rostedt@goodmis.org>
    > 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
    cache.

    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.023 / U:118.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site