[PATCH 9/9] drm/amdgpu: WIP add IOCTL interface for per VM BOs

[Christian König]

Am 28.08.2017 um 06:21 schrieb zhoucm1:
>
>
> On 2017年08月27日 18:03, Christian König wrote:
>> Am 25.08.2017 um 21:19 schrieb Christian König:
>>> Am 25.08.2017 um 18:22 schrieb Marek Olšák:
>>>> On Fri, Aug 25, 2017 at 3:00 PM, Christian König
>>>> <deathsimple at vodafone.de> wrote:
>>>>> Am 25.08.2017 um 12:32 schrieb zhoucm1:
>>>>>>
>>>>>>
>>>>>> On 2017年08月25日 17:38, Christian König wrote:
>>>>>>> From: Christian König <christian.koenig at amd.com>
>>>>>>>
>>>>>>> Add the IOCTL interface so that applications can allocate per VM 
>>>>>>> BOs.
>>>>>>>
>>>>>>> Still WIP since not all corner cases are tested yet, but this 
>>>>>>> reduces
>>>>>>> average
>>>>>>> CS overhead for 10K BOs from 21ms down to 48us.
>>>>>> Wow, cheers, eventually you get per vm bo to same reservation 
>>>>>> with PD/pts,
>>>>>> indeed save a lot of bo list.
>>>>>
>>>>> Don't cheer to loud yet, that is a completely constructed test case.
>>>>>
>>>>> So far I wasn't able to archive any improvements with any real 
>>>>> game on this
>>>>> with Mesa.
> With thinking more, too many BOs share one reservation, which could 
> result in reservation lock often is busy, if eviction or destroy also 
> happens often in the meaning time, then which could effect VM update 
> and CS submission as well.

That's exactly the reason why I've added code to the BO destroy path to 
avoid at least some of the problems. But yeah, that's only the tip of 
the iceberg of problems with that approach.

> Anyway, this is very good start and try that we reduce CS overhead, 
> especially we've seen "reduces average CS overhead for 10K BOs from 
> 21ms down to 48us. ".

Actually, it's not that good. See this is a completely build up test 
case on a kernel with lockdep and KASAN enabled.

In reality we usually don't have so many BOs and so far I wasn't able to 
find much of an improvement in any real world testing.

Regards,
Christian.