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]

Re: [PATCH] MEMORY_BARRIER default


>>>>> 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]