[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