Re: [PATCH 4/6] drm/ttm: add the infrastructur for pipelined evictions

["Christian König" <deathsimple@vodafone.de>]

Am 02.07.2016 um 10:39 schrieb Thomas Hellstrom:
> Christian,
>
> Thanks for doing this!
> A question below:
>
> On 06/15/2016 01:44 PM, Christian König wrote:
>> From: Christian König <christian.koenig@amd.com>
>>
>> Free up the memory immediately, remember the last eviction for each domain and
>> make new allocations depend on the last eviction to be completed.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/gpu/drm/ttm/ttm_bo.c      | 49 ++++++++++++++++++---
>>   drivers/gpu/drm/ttm/ttm_bo_util.c | 92 +++++++++++++++++++++++++++++++++++++++
>>   include/drm/ttm/ttm_bo_driver.h   | 24 ++++++++++
>>   3 files changed, 160 insertions(+), 5 deletions(-)
>>
>>
>>   
>>   	/*
>>   	 * Protected by @io_reserve_mutex:
>> @@ -298,6 +301,11 @@ struct ttm_mem_type_manager {
>>   	 */
>>   
>>   	struct list_head lru;
>> +
>> +	/*
>> +	 * Protected by @move_lock.
>> +	 */
>> +	struct fence *move;
>>   };
>>   
> Did you look at protecting the move fence with RCU? I figure where there
> actually is a fence it doesn't matter much but in the fastpath where
> move is NULL we'd be able to get rid of a number of locking cycles.

Yeah, thought about that as well.

>
> I guess though there might be both licensing implications and
> requirements to using kfree_rcu() to free the fence.

The problem wasn't licensing (but it is good that you point that out I 
wasn't aware of this problem), but that that the existing fence RCU 
function wouldn't worked here and I didn't had time to take a closer look.

Should be relative easy to switch the read path over, because we already 
free the fences RCU protected.

Regards,
Christian.

>
> /Thomas
>
>
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel