[lkml]   [2005]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Possible memory ordering bug in page reclaim?
    On Sat, Oct 15, 2005 at 04:07:02PM -0700, David S. Miller wrote:
    > From: Andrea Arcangeli <>
    > Date: Sat, 15 Oct 2005 22:07:01 +0200
    > > sure see alpha:
    > >
    > > __asm__ __volatile__(
    > > "1: ldq_l %0,%1\n"
    > > " addq %0,%3,%2\n"
    > > " addq %0,%3,%0\n"
    > > " stq_c %0,%1\n"
    > > " beq %0,2f\n"
    > > " mb\n"
    > >
    > > the memory barrier is applied way after the write is visible to other
    > > cpus, you can even get an irq before the mb and block there for some
    > > usec.
    > For atomic operations returning values, there must be a memory
    > barrier both before and after the atomic operation. This is
    > defined in Documentation/atomic_ops.txt, so Alpha needs to be
    > fixed to add a memory barrier at the beginning of these
    > assembler sequences.

    My opinion is that we don't need a barrier even _after_ ll/sc sequences
    on Alpha - it's redundant; perhaps it's just a historical baggage.
    I strongly believe that ll/sc _does_ imply an SMP memory barrier, as can
    be seen from instructions timing: a standalone mb takes tens of cycles,
    the mb before/after ll/sc takes 0 to 1 cycle on ev6 (a bit more on ev56)
    depending on instruction slotting.
    Note that superfluous mb's around atomic stuff still can hurt -
    Alpha mb instruction also flushes IO write buffers, so it can
    be _extremely_ expensive under heavy IO...

    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: 2005-10-16 21:44    [W:0.020 / U:3.940 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site