[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