Messages in this thread | | | Date | Sun, 16 Oct 2005 23:36:00 +0400 | From | Ivan Kokshaysky <> | Subject | Re: Possible memory ordering bug in page reclaim? |
| |
On Sat, Oct 15, 2005 at 04:07:02PM -0700, David S. Miller wrote: > From: Andrea Arcangeli <andrea@suse.de> > 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...
Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |