[PATCH 1/2] drm/ttm: fix busy memory to fail other user v6
Koenig, Christian
Christian.Koenig at amd.com
Wed May 8 09:03:34 UTC 2019
Am 08.05.19 um 10:34 schrieb Thomas Hellstrom:
> [SNIP]
>>>> No, what I mean is to add the acquire_ctx as separate parameter to
>>>> ttm_mem_evict_first().
>>>>
>>>> E.g. we only need it in this function and it is actually not related
>>>> to the ttm operation context filled in by the driver.
>>>
>>> FWIW, I think it would be nice at some point to have a reservation
>>> context being part of the ttm operation context, so that validate and
>>> evict could do sleeping reservations, and have bos remain on the lru
>>> even when reserved...
>> Yeah, well that's exactly what the ctx->resv parameter is good for :)
>
> Hmm. I don't quite follow? It looks to me like ctx->resv is there to
> work around recursive reservations?
Well yes and no, this is to allow eviction of BOs which share the same
reservation object.
>
>
> What I'm after is being able to do sleeping reservations within validate
> and evict and open up for returning -EDEADLK. One benefit would be to
> scan over the LRU lists, reserving exactly those bos we want to evict,
> and when all are reserved, we evict them. If we hit an -EDEADLK while
> evicting we need to restart. Then we need an acquire_ctx in the
> ttm_operation_ctx.
The acquire_ctx is available from the BO you try to find space for.
But we already tried this approach and it doesn't work. We have a lot of
BOs which now share the same reservation object and so would cause an
-EDEADLK.
>> And yes, we do keep the BOs on the LRU even when they are reserved.
>
> static inline int ttm_bo_reserve(struct ttm_buffer_object *bo,
> bool interruptible, bool no_wait,
> struct ww_acquire_ctx *ticket)
ttm_bo_reserve() is not always used any more outside of TTM. The for
DMA-buf as well as amdgpu VMs code the reservation object is locked
without calling ttm_bo_reserve now.
Regards,
Christian.
>
> /Thomas
More information about the amd-gfx
mailing list