lkml.org 
[lkml]   [2008]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: MMIO and gcc re-ordering issue
    Date
    On Wednesday 11 June 2008 13:40, Benjamin Herrenschmidt wrote:
    > On Wed, 2008-06-11 at 13:29 +1000, Nick Piggin wrote:
    > > Exactly, yes. I guess everybody has had good intentions here, but
    > > as noticed, what is lacking is coordination and documentation.
    > >
    > > You mention strong ordering WRT spin_unlock, which suggests that
    > > you would prefer to take option #2 (the current powerpc one): io/io
    > > is ordered and io is contained inside spinlocks, but io/cacheable
    > > in general is not ordered.
    >
    > IO/cacheable -is- ordered on powepc in what we believe is the direction
    > that matter: IO reads are fully ordered vs. anything and IO writes are
    > ordered vs. previous cacheable stores. The only "relaxed" situation is
    > IO writes followed by cacheable stores, which I believe shouldn't be
    > a problem. (except for spinlocks for which we use the flag trick)

    Spinlocks... mutexes, semaphores, rwsems, rwlocks, bit spinlocks, bit
    mutexes, open coded bit locks (of which there are a number floating
    around in drivers/).

    But even assuming you get all of that fixed up. I wonder what is such
    a big benefit to powerpc that you'll rather add the exception "cacheable
    stores are not ordered with previous io stores" than to say "any driver
    which works on x86 will work on powerpc as far as memory ordering goes"?
    (don't you also need something to order io reads with cacheable reads?
    as per my observation that your rmb is broken according to IBM docs)

    Obviously you already have a sync instruction in your writel, so 1)
    adding a second one doesn't slow it down by an order of mangnitude or
    anything, just some small factor; and 2) you obviously want to be
    converting high performance drivers to a more relaxed model anyway
    regardless of whether there is one sync or two in there.

    Has this ever been measured or thought carefully about? Beyond the
    extent of "one sync good, two sync bad" ;)


    \
     
     \ /
      Last update: 2008-06-11 06:09    [W:4.025 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site