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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
