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

From: "Zhou, David(ChunMing)" <David1.Zhou-5C7GfCeVMHo@public.gmane.org>
To: "Christian K鰊ig" <deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
Cc: "Zhou,
	David(ChunMing)" <David1.Zhou-5C7GfCeVMHo@public.gmane.org>,
	"Olsak, Marek" <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>,
	"Marek Ol?醟" <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	amd-gfx
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 9/9] drm/amdgpu: WIP add IOCTL interface for per VM BOs
Date: Mon, 28 Aug 2017 12:59:08 +0000	[thread overview]
Message-ID: <MWHPR1201MB0206D4E64E86D7AADA159A47B49E0@MWHPR1201MB0206.namprd12.prod.outlook.com> (raw)
In-Reply-To: <0006623b-f042-dda0-b6a2-425dc568ff03-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>

[-- Attachment #1.1: Type: text/plain, Size: 2142 bytes --]

I will push our vulkan guys to test it, their bo list is very long.

发自坚果 Pro

Christian K鰊ig <deathsimple@vodafone.de> 于 2017年8月28日 下午7:55写道：

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@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@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.

[-- Attachment #1.2: Type: text/html, Size: 4124 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx