[PATCH] MEMORY_BARRIER default
David Mosberger
davidm@napali.hpl.hp.com
Tue Apr 2 14:40:00 GMT 2002
>>>>> On 02 Apr 2002 14:30:00 -0800, Ulrich Drepper <drepper@redhat.com> said:
Uli> On Mon, 2002-03-25 at 09:41, David Mosberger wrote:
>> It seems to me that on ia64, MEMORY_BARRIER should expand into:
>>
>> asm volatile ("mf" ::: "memory")
Uli> Yes, and I've added an appropriate change. I'm not entirely
Uli> clear how the mf.a form comes into play. We have separate
Uli> READ_MEMORY_BARRIER and WRITE_MEMORY_BARRIER macros and mf.a
Uli> might fit for one of them.
Oh, no, that's not the intended use of mf.a. It's basically intended
for implemented IN/OUT instruction emulation. It forces "device
acceptance", which adds an off-chip roundtrip. Very bad for
performance. In contrast, mf is fairly light-weight (doesn't cause
any pipeline disruption; just forces ordering).
It would be nice to have a way to take advantage of ia64's
acquire/release model, since there are cases where this is much closer
to what an application really wants. Hans and I briefly discussed
this, but neither of us has had the time to really pursue this.
--david
More information about the Libc-hacker
mailing list