The page tables can be enabled/disabled
on a per VMID basis, but memory management in the core kernel
works with pages.
So you need a relocation table just because of this. Additional to that the TLB is more than big enough, so there isn't much performance gain if you use huge pages.
Please note that the VM subsystem also supports giant pages, so if your application manages to allocate things in chunks of at least 1GB you only get a single page table entry for that.
Regards,
Christian.
Am 01.12.20 um 12:28 schrieb Smith John:
So you need a relocation table just because of this. Additional to that the TLB is more than big enough, so there isn't much performance gain if you use huge pages.
Please note that the VM subsystem also supports giant pages, so if your application manages to allocate things in chunks of at least 1GB you only get a single page table entry for that.
Regards,
Christian.
Am 01.12.20 um 12:28 schrieb Smith John:
Hi Christian,Thanks for your reply. I agree with you that the VMID0 is special and remapping is important. I was not sure if different VIMDs could have different settings, such as enable/disable page tables.Or to put it another way, I was wondering if the hardware supports purely physical addressing like the real mode in CPUs, or page tables are essential for the hardware.More specifically, assuming it supports "real mode", to copy things from A to B, one could allocate rings which are accessible by MMIO and fill sdma packets using physical address to transfer data.
Regards,Smith
Christian König <ckoenig.leichtzumerken@xxxxxxxxx> 于2020年12月1日周二 下午5:50写道：
Am 01.12.20 um 07:58 schrieb Smith John:
Hello!I was trying to figure out the impact of gpu page tables on applications' performance. I noticed that there are 16 vmids supported by the hardware Vega 10. Is it possible to use physical address directly in some vmids, or use physical address globally?
No. VMID0 is used by the kernel for jobs like copying things from A to B and even there we use the VM remapping functionality.
Regards,
Christian.
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
