a quetion about buffer migration for user mapped bo.

a quetion about buffer migration for user mapped bo.

[258454946]

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

Hi Guys,


I am a newbee of gfx development. Recently, I am researching amdgpu open source driver, and encounter a problem, but do not find the answer.


We know the user maybe map a gem backing buffer for reading/writing and hold the mapping for a long term. while, kernel driver will also moves the user mapped bo to other memory region. vram ->gtt, gtt->vram, even it may be swaped out under OOM case.


So, my question is how driver prevents kernel ttm from moving the user mapped bo while user is accessing it?


Thanks for your attention!


Lizhi.

[-- Attachment #1.2: Type: text/html, Size: 754 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

Re: a quetion about buffer migration for user mapped bo.

[Andrey Grodzovsky]

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

 From my understanding and looking at the code I think we don't prevent 
but rather invalidate current user mappings and use subsequent page 
faults to map into user space process the pages from the new location. 
Check what this function is doing during move - 
https://elixir.bootlin.com/linux/v5.12-rc5/source/drivers/gpu/drm/ttm/ttm_bo.c#L238

Andrey

On 2021-04-05 12:01 p.m., 258454946 wrote:
> Hi Guys,
>
> I am a newbee of gfx development. Recently, I am researching amdgpu 
> open source driver, and encounter a problem, but do not find the answer.
>
> We know the user maybe map a gem backing buffer for reading/writing 
> and hold the mapping for a long term. while, kernel driver will also 
> moves the user mapped bo to other memory region. vram ->gtt, 
> gtt->vram, even it may be swaped out under OOM case.
>
> So, my question is how driver prevents kernel ttm from moving the user 
> mapped bo while user is accessing it?
>
> Thanks for your attention!
>
> Lizhi.
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[-- Attachment #1.2: Type: text/html, Size: 2186 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

Re: a quetion about buffer migration for user mapped bo.

[Christian König]

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

Yes, Andrey is right.

A top level explanation is that we don't prevent moving the buffer but 
rather we prevent user space from accessing it.

Regards,
Christian.

Am 05.04.21 um 18:34 schrieb Andrey Grodzovsky:
>
> From my understanding and looking at the code I think we don't prevent 
> but rather invalidate current user mappings and use subsequent page 
> faults to map into user space process the pages from the new location. 
> Check what this function is doing during move - 
> https://elixir.bootlin.com/linux/v5.12-rc5/source/drivers/gpu/drm/ttm/ttm_bo.c#L238
>
> Andrey
>
> On 2021-04-05 12:01 p.m., 258454946 wrote:
>> Hi Guys,
>>
>> I am a newbee of gfx development. Recently, I am researching amdgpu 
>> open source driver, and encounter a problem, but do not find the answer.
>>
>> We know the user maybe map a gem backing buffer for reading/writing 
>> and hold the mapping for a long term. while, kernel driver will also 
>> moves the user mapped bo to other memory region. vram ->gtt, 
>> gtt->vram, even it may be swaped out under OOM case.
>>
>> So, my question is how driver prevents kernel ttm from moving the 
>> user mapped bo while user is accessing it?
>>
>> Thanks for your attention!
>>
>> Lizhi.
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 3351 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

Re: a quetion about buffer migration for user mapped bo.

[صالح المسعودي]

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

771763840

[-- Attachment #1.2: Type: text/html, Size: 88 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

Re: a quetion about buffer migration for user mapped bo.

[صالح المسعودي]

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

771763840

[-- Attachment #1.2: Type: text/html, Size: 84 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