This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
>>>>> 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
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |