Re: Memory Barrier Definitions

[Linus Torvalds]

On Mon, 13 May 2002, David Mosberger wrote:
>
>  This would have to be complemented by a set of barrier routines which
> will achieve the desired ordering on machines that don't have the
> acquire/release model of ia64 (and on ia64, they would expand into
> nothing).

Earth to ia64, earth calling...

Until ia64 is a noticeable portion of the installed base, and indeed,
until it has shown that it can survive at all, we're not going to design
the Linux SMP memory ordering around that architecture.

If that means that ia64 will have to do strange things and maybe cannot
take advantage of its strange memory models, that's ok. Because reality
rules.

We're _not_ going to make up a complicated, big fancy new model. We might
tweak the current one a bit. And if that means that some architectures get
heavier barriers than they strictly need, then so be it. There are two
overriding concerns:

 - sanity: maybe it's better to have one mb() that is a sledgehammer but
   obvious, than it is to have many subtle variations that are just asking
   for subtle bugs.

 - x86 _owns_ the market right now, and we're not going to make up
   barriers that add overhead to x86. We may add barriers that end up
   being no-op's on x86 (because it is fairly ordered anyway), but
   basically it should be designed for the _common_ case, not for some
   odd-ball architecture that has sold machines mostly for test purposes.

The x86 situation is obviously just today. In five or ten years maybe
everybody agrees that we should follow the ia-64 model, and x86 can do
strange things that end up being slow.

			Linus