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 at 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 at 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
>
>
>
