From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/6] drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held
Date: Wed, 28 Nov 2012 13:15:38 +0100 [thread overview]
Message-ID: <50B6006A.6030107@canonical.com> (raw)
In-Reply-To: <50B5FB82.9020904@vmware.com>
Op 28-11-12 12:54, Thomas Hellstrom schreef:
> On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
>> By removing the unlocking of lru and retaking it immediately, a race is
>> removed where the bo is taken off the swap list or the lru list between
>> the unlock and relock. As such the cleanup_refs code can be simplified,
>> it will attempt to call ttm_bo_wait non-blockingly, and if it fails
>> it will drop the locks and perform a blocking wait, or return an error
>> if no_wait_gpu was set.
>>
>> The need for looping is also eliminated, since swapout and evict_mem_first
>> will always follow the destruction path, so no new fence is allowed
>> to be attached. As far as I can see this may already have been the case,
>> but the unlocking / relocking required a complicated loop to deal with
>> re-reservation.
>>
>> The downside is that ttm_bo_cleanup_memtype_use is no longer called with
>> reservation held, so drivers must be aware that move_notify with a null
>> parameter doesn't require a reservation.
>
> Why can't we unreserve *after* ttm_bo_cleanup_memtype_use? That's not
> immediately clear from this patch.
Because we would hold the reservation while waiting and with the object still
on swap and lru lists still, that would defeat the whole purpose of keeping
the object on multiple lists, plus break current code that assumes bo's on the
those lists can always be reserved.
the if (ret && !no_wait_gpu) path has to drop the reservation and lru lock, and
isn't guaranteed to be able to retake it. Maybe it could be guaranteed now, but
I'm sure that would not be the case if the reservations were shared across
devices.
The alternatives are worse: doing a blocking reserve would rightfully anger lockdep,
and how do you want to handle tryreserve failing?
Since there is a path in which no reservation can be taken, to weed out bugs I felt it
would be better that any bugs that trigger from not holding a reservation would be
easier to find if it happens all the time, instead of only in some corner cases.
~Maarten
next prev parent reply other threads:[~2012-11-28 12:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-28 11:25 [PATCH 1/6] drm/ttm: change fence_lock to inner lock Maarten Lankhorst
2012-11-28 11:25 ` [PATCH 2/6] drm/radeon: allow move_notify to be called without reservation Maarten Lankhorst
2012-11-28 11:25 ` [PATCH 3/6] drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held Maarten Lankhorst
2012-11-28 11:54 ` Thomas Hellstrom
2012-11-28 12:15 ` Maarten Lankhorst [this message]
2012-11-28 13:21 ` Thomas Hellstrom
2012-11-28 13:55 ` Maarten Lankhorst
2012-11-28 14:23 ` Thomas Hellstrom
2012-11-28 14:46 ` Maarten Lankhorst
2012-11-28 15:10 ` Thomas Hellstrom
2012-11-28 18:32 ` Maarten Lankhorst
2012-11-28 19:21 ` Thomas Hellstrom
2012-11-28 22:26 ` Maarten Lankhorst
2012-11-29 9:42 ` Thomas Hellstrom
2012-11-29 11:36 ` [PATCH 3/6] drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3 Maarten Lankhorst
2012-11-29 20:43 ` Thomas Hellstrom
2012-11-28 12:28 ` [PATCH 3/6] drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held Maarten Lankhorst
2012-11-28 11:25 ` [PATCH 4/6] drm/ttm: cope with reserved buffers on swap list in ttm_bo_swapout, v2 Maarten Lankhorst
2012-11-28 14:27 ` Thomas Hellstrom
2012-11-28 11:25 ` [PATCH 5/6] drm/ttm: cope with reserved buffers on lru list in ttm_mem_evict_first, v2 Maarten Lankhorst
2012-11-28 11:25 ` [PATCH 6/6] drm/ttm: remove no_wait_reserve, v3 Maarten Lankhorst
2012-11-28 11:40 ` [PATCH 1/6] drm/ttm: change fence_lock to inner lock Thomas Hellstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50B6006A.6030107@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=m.b.lankhorst@gmail.com \
--cc=thellstrom@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.