From: David Howells <dhowells@redhat.com>
In-Reply-To: <Pine.LNX.4.64.0603080817500.5481@schroedinger.engr.sgi.com> 
References: <Pine.LNX.4.64.0603080817500.5481@schroedinger.engr.sgi.com>  <31492.1141753245@warthog.cambridge.redhat.com> 
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Document Linux's memory barriers 
Date: Wed, 08 Mar 2006 17:35:08 +0000
Message-ID: <10414.1141839308@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1931
Lines: 44

Christoph Lameter <clameter@engr.sgi.com> wrote:

> You need to explain the difference between the compiler reordering and the 
> control of the compilers arrangement of loads and stores and the cpu 
> reordering of stores and loads.

Hmmm... I would hope people looking at this doc would understand that, but
I'll see what I can come up with.

> Note that IA64 has a much more complete set of means to reorder stores and
> loads. i386 and x84_64 processors can only do limited reordering. So it may
> make sense to deal with general reordering and then explain i386 as a
> specific limited case.

Don't you need to use sacrifice_goat() for controlling the IA64? :-)

Besides, I'm not sure that I need to explain that any CPU is a limited case;
I'm primarily trying to define the basic minimal guarantees you can expect
from using a memory barrier, and what might happen if you don't. It shouldn't
matter which arch you're dealing with, especially if you're writing a driver.

I tried to create arch-specific sections for describing arch-specific implicit
barriers and the extent of the explicit memory barriers on each arch, but the
i386 section was generating lots of exceptions that it looked infeasible to
describe them; besides, you aren't allowed to rely on such features outside of
arch code (I count arch-specific drivers as "arch code" for this).

> See the "Intel Itanium Architecture Software Developer's Manual" 
> (available from intels website). Look at Volume 1 section 2.6 
> "Speculation" and 4.4 "Memory Access"

I've added that to the refs, thanks.

> Also the specific barrier functions of various locking elements varies to 
> some extend.

Please elaborate.

David
-
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/