Messages in this thread | | | From | David Mosberger <> | Date | Thu, 9 May 2002 08:00:35 -0700 | Subject | Re: Memory Barrier Definitions |
| |
>>>>> On Thu, 9 May 2002 17:36:46 +1000, Rusty Russell <rusty@rustcorp.com.au> said:
Rusty> On Wed, 8 May 2002 10:07:08 -0700 David Mosberger Rusty> <davidm@napali.hpl.hp.com> wrote:
>> The ia64 memory ordering model is quite orthogonal to the one >> that Linux uses (which is based on the Alpha instructions): Linux >> distinguishes between read and write memory barriers. ia64 uses >> an acquire/release model instead. An acquire orders all *later* >> memory accesses and a release orders all *earlier* accesses >> (regardless of whether they are reads or writes). Another >> difference is that the acquire/release semantics is attached to >> load/store instructions, respectively. This means that in an >> ideal world, ia64 would rarely need to use the memory barrier >> instruction.
Rusty> Hmmm... could you explain more? You're saying that every Rusty> load is an "acquire" and every store a "release"? Or that Rusty> they can be flagged that way, but aren't always?
The latter: loads can have "acquire" semantics and stores can have "release" semantics. For example, at the assembly level, ld8.acq would be an 8-byte load with acquire semantics, st8.rel an 8-byte store with release semantics. At the C level, acquire/release semantics is used for all accesses to "volatile" variables.
One way to think of all this is that using .acq/.rel for *all* memory accesses will give you a memory model that exactly matches that of a Pentium III.
Rusty> Does this means that an "acquire" means "all accesses after Rusty> this insn (in the code stream) must occur after this insn (in Rusty> time)"?
Yes.
Rusty> Does that only apply to the address that instruction Rusty> touched, or all?
No, the address doesn't matter (data dependencies are always honored).
--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/
| |