[Nouveau] [PATCH 2/2] nouveau: Do not add most bo's to the global bo list.

[Patrick Baggett]

On Wed, Feb 25, 2015 at 10:35 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> pthread_mutex_lock had *better* imply a compiler barrier across which
> code can't be moved... which is very different from the printf case
> where it might have done it due to register pressure or who knows
> what.
>
In the dummy function, register pressure was certainly not an issue, but
point taken. Still, a compiler barrier prevents reordering like:

x = *a;
y = *a;
pthread_mutex_lock()

This changes the external visibility ordering and is certainly NOT ok.


However, I contend that it doesn't stop:

const int loaded = *a;
x = loaded;
pthread_mutex_lock();
y = loaded;

Because this doesn't change the external visibility behavior, it just
changes whether a value is reloaded. It doesn't break the ordering of a
memory barrier at all.


> If code like
>
> x = *a;
> pthread_mutex_lock or unlock or __memory_barrier()
> y = *a;
>
> doesn't cause a to get loaded twice, then the compiler's in serious
> trouble. Basically functions like pthread_mutex_lock imply that all
> memory is changed to the compiler, and thus need to be reloaded.
>
> Well, I've said before and I might be alone, but I disagree with you. The
compiler is under no requirement to reload (*a) because a lock was changed.
It does, but it doesn't have to. It's fine if you guys don't want to change
it. It may never be a problem with gcc.

This is the definition of pthread_mutex_lock() in glibc. There aren't any
magic hints that this invalidates memory:

extern int pthread_mutex_lock (pthread_mutex_t *__mutex)
__THROWNL __nonnull ((1));

THOWNL is attribute((nothrow)).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150225/1d46e029/attachment.html>