<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 9:07 AM, Maarten Lankhorst <span dir="ltr"><<a href="mailto:maarten.lankhorst@ubuntu.com" target="_blank">maarten.lankhorst@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Op 25-02-15 om 16:04 schreef Patrick Baggett:<br>
<div><div class="h5">> On Wed, Feb 25, 2015 at 8:59 AM, Maarten Lankhorst <<br>
> <a href="mailto:maarten.lankhorst@ubuntu.com">maarten.lankhorst@ubuntu.com</a>> wrote:<br>
><br>
>> Op 25-02-15 om 15:11 schreef Emil Velikov:<br>
>>> On 24 February 2015 at 09:01, Maarten Lankhorst<br>
>>> <<a href="mailto:maarten.lankhorst@ubuntu.com">maarten.lankhorst@ubuntu.com</a>> wrote:<br>
>>>> Only add wrapped bo's and bo's that have been exported through flink or<br>
>> dma-buf.<br>
>>>> This avoids a lock in the common case, and decreases traversal needed<br>
>> for importing<br>
>>>> a dma-buf or flink.<br>
>>>><br>
>>>> Signed-off-by: Maarten Lankhorst <<a href="mailto:maarten.lankhorst@ubuntu.com">maarten.lankhorst@ubuntu.com</a>><br>
>>>> ---<br>
>>>> nouveau/nouveau.c | 47 +++++++++++++++++++++++------------------------<br>
>>>> 1 file changed, 23 insertions(+), 24 deletions(-)<br>
>>>><br>
>>>> diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c<br>
>>>> index 1c723b9..d411523 100644<br>
>>>> --- a/nouveau/nouveau.c<br>
>>>> +++ b/nouveau/nouveau.c<br>
>>>> @@ -349,8 +349,8 @@ nouveau_bo_del(struct nouveau_bo *bo)<br>
>>>> struct nouveau_bo_priv *nvbo = nouveau_bo(bo);<br>
>>>> struct drm_gem_close req = { bo->handle };<br>
>>>><br>
>>>> - pthread_mutex_lock(&nvdev->lock);<br>
>>>> - if (nvbo->name) {<br>
>>>> + if (nvbo->head.next) {<br>
>>>> + pthread_mutex_lock(&nvdev->lock);<br>
>>>> if (atomic_read(&nvbo->refcnt) == 0) {<br>
>>>> DRMLISTDEL(&nvbo->head);<br>
>>>> /*<br>
>>>> @@ -365,8 +365,6 @@ nouveau_bo_del(struct nouveau_bo *bo)<br>
>>>> }<br>
>>>> pthread_mutex_unlock(&nvdev->lock);<br>
>>>> } else {<br>
>>>> - DRMLISTDEL(&nvbo->head);<br>
>>>> - pthread_mutex_unlock(&nvdev->lock);<br>
>>>> drmIoctl(bo->device->fd, DRM_IOCTL_GEM_CLOSE, &req);<br>
>>>> }<br>
>>>> if (bo->map)<br>
>>>> @@ -379,7 +377,6 @@ nouveau_bo_new(struct nouveau_device *dev, uint32_t<br>
>> flags, uint32_t align,<br>
>>>> uint64_t size, union nouveau_bo_config *config,<br>
>>>> struct nouveau_bo **pbo)<br>
>>>> {<br>
>>>> - struct nouveau_device_priv *nvdev = nouveau_device(dev);<br>
>>>> struct nouveau_bo_priv *nvbo = calloc(1, sizeof(*nvbo));<br>
>>>> struct nouveau_bo *bo = &nvbo->base;<br>
>>>> int ret;<br>
>>>> @@ -397,10 +394,6 @@ nouveau_bo_new(struct nouveau_device *dev,<br>
>> uint32_t flags, uint32_t align,<br>
>>>> return ret;<br>
>>>> }<br>
>>>><br>
>>>> - pthread_mutex_lock(&nvdev->lock);<br>
>>>> - DRMLISTADD(&nvbo->head, &nvdev->bo_list);<br>
>>>> - pthread_mutex_unlock(&nvdev->lock);<br>
>>>> -<br>
>>>> *pbo = bo;<br>
>>>> return 0;<br>
>>>> }<br>
>>>> @@ -457,6 +450,18 @@ nouveau_bo_wrap_locked(struct nouveau_device *dev,<br>
>> uint32_t handle,<br>
>>>> return -ENOMEM;<br>
>>>> }<br>
>>>><br>
>>>> +static void<br>
>>>> +nouveau_bo_make_global(struct nouveau_bo_priv *nvbo)<br>
>>>> +{<br>
>>>> + if (!nvbo->head.next) {<br>
>>>> + struct nouveau_device_priv *nvdev =<br>
>> nouveau_device(nvbo->base.device);<br>
>>>> + pthread_mutex_lock(&nvdev->lock);<br>
>>>> + if (!nvbo->head.next)<br>
> I guess the bo_make_global call is not particularly sensitive, so<br>
>> removing's fine with me.<br>
>><br>
> I would be worried about the duplicated check. It seems like a "smart"<br>
> compiler could cache the value of "nvbo->head.next" (unless marked as<br>
> volatile), rendering the second if() useless. If the field is marked<br>
> volatile, then of course, this does not apply.<br>
><br>
</div></div>In that case I would be worried about a compiler that ignores the acquire semantics of pthread_mutex_lock..<br></blockquote><div><br></div><div>This isn't about the acquire semantics here, because you're reading it on both sides of the lock. The compiler need not reorder the reads at all, merely just save the value of the first read. Unless the compiler knows that the value can change after the lock is acquired, it can simply cache the result. Consider the nearly identical transformation:<br><br></div><div>const int condition = (!nvbo->head.next);<br></div><div>if(condition){<br></div><div> pthread_mutex_lock(...);<br></div><div> if(condition){ //redundant, already can assert it is true<br> ...<br></div><div><br></div><div>I just wouldn't risk it. The compiler probably makes this transformation already, but even if it doesn't, it <i>can</i>, and that's a bad thing IMO. <br></div><div><br></div><div><br></div><div>Patrick<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
~Maarten<br>
<br>
</font></span></blockquote></div><br></div></div>