2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-25 20:40:26 -04:00
|
|
|
|
2017-12-06 17:49:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-06 20:32:32 -05:00
|
|
|
|
2022-05-09 21:13:35 +02:00
|
|
|
|
2019-12-17 16:57:30 -06:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-18 16:53:03 +01:00
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2022-04-19 12:21:45 +02:00
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-20 14:10:24 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-29 16:08:32 +08:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-02-13 14:22:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2019-08-07 22:31:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-02-13 14:22:58 +01:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-02-13 14:22:58 +01:00
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-02-15 14:10:19 -05:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-04-19 09:53:29 +08:00
|
|
|
|
|
|
|
|
|
2017-01-30 11:09:31 +01:00
|
|
|
|
2017-07-25 16:35:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-22 15:34:00 +08:00
|
|
|
|
|
|
|
|
|
2017-12-05 15:23:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-01 16:24:33 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-05 15:23:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-09 11:11:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-14 12:15:27 -04:00
|
|
|
|
2023-06-09 11:11:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-14 12:15:27 -04:00
|
|
|
|
2024-05-29 18:12:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-03 15:23:14 -05:00
|
|
|
|
2018-05-14 12:15:27 -04:00
|
|
|
|
2017-08-31 15:55:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-25 21:03:40 +08:00
|
|
|
|
2017-08-31 15:55:00 -04:00
|
|
|
|
2019-07-16 18:25:01 +08:00
|
|
|
|
2024-05-29 17:57:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-12 18:17:24 -05:00
|
|
|
|
2023-03-08 11:00:16 +08:00
|
|
|
|
|
|
|
|
|
2023-03-08 22:56:43 +08:00
|
|
|
|
|
|
|
|
|
2023-03-08 11:00:16 +08:00
|
|
|
|
2024-05-29 17:53:11 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-08 11:00:16 +08:00
|
|
|
|
2024-02-06 16:03:17 -05:00
|
|
|
|
2025-09-10 16:57:25 -04:00
|
|
|
|
2023-03-08 11:00:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-08 22:56:43 +08:00
|
|
|
|
|
|
|
|
|
2023-03-08 11:00:16 +08:00
|
|
|
|
|
|
|
|
|
2023-03-08 22:56:43 +08:00
|
|
|
|
|
|
|
|
|
2023-03-08 11:00:16 +08:00
|
|
|
|
2020-09-22 05:54:18 -07:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-02 15:53:01 -05:00
|
|
|
|
2020-11-25 21:03:01 +08:00
|
|
|
|
2019-08-30 14:38:37 +02:00
|
|
|
|
2022-09-14 16:35:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 16:54:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-30 14:41:19 +02:00
|
|
|
|
2024-01-30 14:34:41 -05:00
|
|
|
|
2024-01-11 23:21:13 -08:00
|
|
|
|
2024-01-25 14:12:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-11 23:21:13 -08:00
|
|
|
|
2024-01-25 14:12:43 -05:00
|
|
|
|
|
|
|
|
|
drm/amdgpu: Change AMDGPU_VA_RESERVED_TRAP_SIZE to 64KB
Currently, AMDGPU_VA_RESERVED_TRAP_SIZE is hardcoded to 8KB, while
KFD_CWSR_TBA_TMA_SIZE is defined as 2 * PAGE_SIZE. On systems with
4K pages, both values match (8KB), so allocation and reserved space
are consistent.
However, on 64K page-size systems, KFD_CWSR_TBA_TMA_SIZE becomes 128KB,
while the reserved trap area remains 8KB. This mismatch causes the
kernel to crash when running rocminfo or rccl unit tests.
Kernel attempted to read user page (2) - exploit attempt? (uid: 1001)
BUG: Kernel NULL pointer dereference on read at 0x00000002
Faulting instruction address: 0xc0000000002c8a64
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
CPU: 34 UID: 1001 PID: 9379 Comm: rocminfo Tainted: G E
6.19.0-rc4-amdgpu-00320-gf23176405700 #56 VOLUNTARY
Tainted: [E]=UNSIGNED_MODULE
Hardware name: IBM,9105-42A POWER10 (architected) 0x800200 0xf000006
of:IBM,FW1060.30 (ML1060_896) hv:phyp pSeries
NIP: c0000000002c8a64 LR: c00000000125dbc8 CTR: c00000000125e730
REGS: c0000001e0957580 TRAP: 0300 Tainted: G E
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24008268
XER: 00000036
CFAR: c00000000125dbc4 DAR: 0000000000000002 DSISR: 40000000
IRQMASK: 1
GPR00: c00000000125d908 c0000001e0957820 c0000000016e8100
c00000013d814540
GPR04: 0000000000000002 c00000013d814550 0000000000000045
0000000000000000
GPR08: c00000013444d000 c00000013d814538 c00000013d814538
0000000084002268
GPR12: c00000000125e730 c000007e2ffd5f00 ffffffffffffffff
0000000000020000
GPR16: 0000000000000000 0000000000000002 c00000015f653000
0000000000000000
GPR20: c000000138662400 c00000013d814540 0000000000000000
c00000013d814500
GPR24: 0000000000000000 0000000000000002 c0000001e0957888
c0000001e0957878
GPR28: c00000013d814548 0000000000000000 c00000013d814540
c0000001e0957888
NIP [c0000000002c8a64] __mutex_add_waiter+0x24/0xc0
LR [c00000000125dbc8] __mutex_lock.constprop.0+0x318/0xd00
Call Trace:
0xc0000001e0957890 (unreliable)
__mutex_lock.constprop.0+0x58/0xd00
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x6fc/0xb60 [amdgpu]
kfd_process_alloc_gpuvm+0x54/0x1f0 [amdgpu]
kfd_process_device_init_cwsr_dgpu+0xa4/0x1a0 [amdgpu]
kfd_process_device_init_vm+0xd8/0x2e0 [amdgpu]
kfd_ioctl_acquire_vm+0xd0/0x130 [amdgpu]
kfd_ioctl+0x514/0x670 [amdgpu]
sys_ioctl+0x134/0x180
system_call_exception+0x114/0x300
system_call_vectored_common+0x15c/0x2ec
This patch changes AMDGPU_VA_RESERVED_TRAP_SIZE to 64 KB and
KFD_CWSR_TBA_TMA_SIZE to the AMD GPU page size. This means we reserve
64 KB for the trap in the address space, but only allocate 8 KB within
it. With this approach, the allocation size never exceeds the reserved
area.
Fixes: 34a1de0f7935 ("drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole")
Reviewed-by: Christian König <christian.koenig@amd.com>
Suggested-by: Felix Kuehling <felix.kuehling@amd.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-26 17:51:28 +05:30
|
|
|
|
2024-01-25 14:12:43 -05:00
|
|
|
|
|
|
|
|
|
2024-01-30 14:34:41 -05:00
|
|
|
|
2024-01-25 14:12:43 -05:00
|
|
|
|
|
|
|
|
|
2024-01-11 23:21:13 -08:00
|
|
|
|
2017-11-06 15:25:37 +01:00
|
|
|
|
2017-06-09 11:26:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-13 14:22:54 +08:00
|
|
|
|
2025-04-25 10:55:07 -04:00
|
|
|
|
2017-12-13 14:22:54 +08:00
|
|
|
|
|
|
|
|
|
2025-04-25 10:55:07 -04:00
|
|
|
|
2017-12-13 14:22:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-01 10:51:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-10 20:02:46 +02:00
|
|
|
|
2017-08-01 10:51:43 +02:00
|
|
|
|
2026-03-13 23:11:44 +05:30
|
|
|
|
2017-08-01 10:51:43 +02:00
|
|
|
|
2017-08-23 16:13:33 +02:00
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
2026-03-13 23:11:44 +05:30
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
|
|
|
|
|
2017-08-23 16:13:33 +02:00
|
|
|
|
|
|
|
|
|
2017-08-01 10:51:43 +02:00
|
|
|
|
2017-06-09 11:26:57 -04:00
|
|
|
|
2018-08-03 19:06:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-28 22:51:32 -04:00
|
|
|
|
2025-06-17 09:49:48 -03:00
|
|
|
|
2024-01-18 20:15:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-28 22:51:32 -04:00
|
|
|
|
|
|
|
|
|
2019-03-18 12:27:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-16 10:33:28 -05:00
|
|
|
|
2020-04-01 12:50:56 +02:00
|
|
|
|
2019-09-16 10:33:28 -05:00
|
|
|
|
2020-04-01 12:50:56 +02:00
|
|
|
|
2019-09-16 10:33:28 -05:00
|
|
|
|
2020-04-07 14:54:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 12:27:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-12 08:02:46 -04:00
|
|
|
|
|
|
|
|
|
2024-03-18 11:43:39 +01:00
|
|
|
|
2021-05-12 08:02:46 -04:00
|
|
|
|
2024-03-18 11:43:39 +01:00
|
|
|
|
2023-10-12 10:35:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-18 11:54:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 12:27:35 +01:00
|
|
|
|
|
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
2021-05-20 14:10:24 +02:00
|
|
|
|
2024-08-20 12:01:22 +02:00
|
|
|
|
2025-06-04 14:28:23 +02:00
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
2021-05-20 14:10:24 +02:00
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 10:54:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-24 10:23:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
2024-10-24 10:23:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
2017-09-08 16:15:08 -07:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2019-12-17 16:57:30 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-04 13:29:49 +01:00
|
|
|
|
|
|
|
|
|
2019-12-17 16:57:30 -06:00
|
|
|
|
2019-12-04 13:29:49 +01:00
|
|
|
|
2026-03-13 23:11:44 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
|
|
|
|
|
2025-08-27 11:45:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-03 18:13:22 -05:00
|
|
|
|
2017-08-03 14:02:13 +02:00
|
|
|
|
|
|
|
|
|
2017-08-09 14:15:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-01 13:25:31 +02:00
|
|
|
|
2017-08-01 11:27:36 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2018-04-19 15:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-27 11:45:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-01 13:25:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-15 17:57:26 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-27 11:45:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2021-06-15 17:23:11 -04:00
|
|
|
|
2017-09-08 14:09:41 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2019-07-19 14:41:12 +02:00
|
|
|
|
2020-04-01 12:50:56 +02:00
|
|
|
|
2019-07-19 14:41:12 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2022-03-15 15:27:45 +01:00
|
|
|
|
|
|
|
|
|
2022-04-12 19:52:16 +08:00
|
|
|
|
2023-02-24 18:22:32 -05:00
|
|
|
|
2024-03-18 11:43:39 +01:00
|
|
|
|
2022-03-15 15:27:45 +01:00
|
|
|
|
2023-04-19 15:17:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-07 14:54:23 +02:00
|
|
|
|
|
|
|
|
|
2019-11-29 12:44:07 +01:00
|
|
|
|
2017-08-25 20:40:26 -04:00
|
|
|
|
2025-09-19 09:27:03 +02:00
|
|
|
|
2017-06-09 11:26:57 -04:00
|
|
|
|
|
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-27 12:48:22 -04:00
|
|
|
|
2017-09-21 16:26:41 -04:00
|
|
|
|
2017-08-26 02:43:06 -04:00
|
|
|
|
2017-09-21 16:26:41 -04:00
|
|
|
|
2018-03-15 17:27:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-28 22:51:32 -04:00
|
|
|
|
|
|
|
|
|
2024-01-18 20:15:42 +01:00
|
|
|
|
drm/amdgpu: use bulk moves for efficient VM LRU handling (v6)
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriously.
Then Christian provided a workaround to not move PD/PT BOs on LRU with below
patch:
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae ("drm/amdgpu: band aid
validating VM PTs")
However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU
instead of one by one.
Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be
validated we move all BOs together to the end of the LRU without dropping the
lock for the LRU.
While doing so we note the beginning and end of this block in the LRU list.
Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do,
we don't move every BO one by one, but instead cut the LRU list into pieces so
that we bulk move everything to the end in just one operation.
Test data:
+--------------+-----------------+-----------+---------------------------------------+
| |The Talos |Clpeak(OCL)|BusSpeedReadback(OCL) |
| |Principle(Vulkan)| | |
+------------------------------------------------------------------------------------+
| | | |0.319 ms(1k) 0.314 ms(2K) 0.308 ms(4K) |
| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K) |
+------------------------------------------------------------------------------------+
| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K) |
|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204 ms(16K)|
|PT BOs on LRU)| | | |
+------------------------------------------------------------------------------------+
| Bulk move | 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213 ms(4K) |
| | | |0.214 ms(8K) 0.225 ms(16K) |
+--------------+-----------------+-----------+---------------------------------------+
After test them with above three benchmarks include vulkan and opencl. We can
see the visible improvement than original, and even better than original with
workaround.
v2: move all BOs include idle, relocated, and moved list to the end of LRU and
put them together.
v3: remove unused parameter and use list_for_each_entry instead of the one with
save entry.
v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that time,
all bo will be back on idle list.
v5: remove amdgpu_vm_move_to_lru_tail_by_list(), use bulk_moveable instread of
validated, and move ttm_bo_bulk_move_lru_tail() also into
amdgpu_vm_move_to_lru_tail().
v6: clean up and fix return value.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-06 10:57:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-18 13:28:46 -06:00
|
|
|
|
|
|
|
|
|
2026-03-16 11:04:46 -04:00
|
|
|
|
|
|
|
|
|
2023-02-23 19:58:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 10:54:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-18 16:53:03 +01:00
|
|
|
|
2020-06-24 23:05:44 -04:00
|
|
|
|
2021-04-22 13:11:39 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-03-28 20:24:53 -04:00
|
|
|
|
2026-02-11 13:28:55 +01:00
|
|
|
|
2016-10-17 15:08:10 +02:00
|
|
|
|
2017-03-29 16:08:32 +08:00
|
|
|
|
2017-08-11 20:00:41 +08:00
|
|
|
|
2017-12-13 14:22:54 +08:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-12 15:15:21 +02:00
|
|
|
|
2019-12-06 16:55:49 +01:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:13:44 +01:00
|
|
|
|
2017-01-30 11:09:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-14 16:02:52 +01:00
|
|
|
|
2017-06-09 11:26:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-25 20:40:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-28 23:29:39 +02:00
|
|
|
|
2024-03-07 21:31:50 +05:30
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
2019-09-23 11:53:08 -04:00
|
|
|
|
|
|
|
|
|
2018-08-03 19:06:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
2019-01-10 16:48:23 +01:00
|
|
|
|
|
|
|
|
|
2025-09-25 18:02:18 +08:00
|
|
|
|
2021-07-02 11:10:52 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2022-04-19 12:21:45 +02:00
|
|
|
|
|
|
|
|
|
2025-08-27 09:28:40 +02:00
|
|
|
|
|
|
|
|
|
2017-08-03 14:02:13 +02:00
|
|
|
|
2023-04-19 15:17:57 +02:00
|
|
|
|
2024-01-03 18:13:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-12 21:30:50 +05:30
|
|
|
|
2019-03-14 09:10:01 +01:00
|
|
|
|
2020-04-01 12:50:56 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2017-03-23 19:36:31 +01:00
|
|
|
|
|
|
|
|
|
2017-08-16 11:13:48 +02:00
|
|
|
|
2022-03-16 17:21:40 -04:00
|
|
|
|
|
|
|
|
|
2023-02-24 18:22:32 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-15 08:51:24 +01:00
|
|
|
|
|
|
|
|
|
2022-03-30 10:53:15 +02:00
|
|
|
|
2024-08-20 12:01:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-30 10:53:15 +02:00
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
2022-03-17 14:29:22 +01:00
|
|
|
|
2019-11-28 14:51:46 +01:00
|
|
|
|
2024-12-19 10:14:10 -05:00
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-18 13:16:03 +01:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-06 14:13:37 +02:00
|
|
|
|
2017-03-13 10:13:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-06 14:13:37 +02:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-13 10:13:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-06 16:55:16 +02:00
|
|
|
|
|
|
|
|
|
2018-07-27 16:56:34 +02:00
|
|
|
|
2022-02-01 16:25:52 +01:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2018-08-21 17:14:32 -04:00
|
|
|
|
2017-11-23 12:57:18 +01:00
|
|
|
|
|
|
|
|
|
2017-04-24 11:09:04 +08:00
|
|
|
|
2017-05-11 14:52:48 -04:00
|
|
|
|
|
|
|
|
|
2017-06-01 09:42:59 -04:00
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|
2024-01-18 20:15:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-15 09:30:05 -07:00
|
|
|
|
2024-08-23 02:04:09 -05:00
|
|
|
|
2022-05-24 10:22:12 -05:00
|
|
|
|
2018-06-28 22:51:32 -04:00
|
|
|
|
2026-02-04 16:41:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-28 22:51:32 -04:00
|
|
|
|
|
|
|
|
|
drm/amdgpu: use bulk moves for efficient VM LRU handling (v6)
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriously.
Then Christian provided a workaround to not move PD/PT BOs on LRU with below
patch:
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae ("drm/amdgpu: band aid
validating VM PTs")
However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU
instead of one by one.
Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be
validated we move all BOs together to the end of the LRU without dropping the
lock for the LRU.
While doing so we note the beginning and end of this block in the LRU list.
Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do,
we don't move every BO one by one, but instead cut the LRU list into pieces so
that we bulk move everything to the end in just one operation.
Test data:
+--------------+-----------------+-----------+---------------------------------------+
| |The Talos |Clpeak(OCL)|BusSpeedReadback(OCL) |
| |Principle(Vulkan)| | |
+------------------------------------------------------------------------------------+
| | | |0.319 ms(1k) 0.314 ms(2K) 0.308 ms(4K) |
| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K) |
+------------------------------------------------------------------------------------+
| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K) |
|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204 ms(16K)|
|PT BOs on LRU)| | | |
+------------------------------------------------------------------------------------+
| Bulk move | 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213 ms(4K) |
| | | |0.214 ms(8K) 0.225 ms(16K) |
+--------------+-----------------+-----------+---------------------------------------+
After test them with above three benchmarks include vulkan and opencl. We can
see the visible improvement than original, and even better than original with
workaround.
v2: move all BOs include idle, relocated, and moved list to the end of LRU and
put them together.
v3: remove unused parameter and use list_for_each_entry instead of the one with
save entry.
v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that time,
all bo will be back on idle list.
v5: remove amdgpu_vm_move_to_lru_tail_by_list(), use bulk_moveable instread of
validated, and move ttm_bo_bulk_move_lru_tail() also into
amdgpu_vm_move_to_lru_tail().
v6: clean up and fix return value.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-08-06 10:57:08 +08:00
|
|
|
|
|
|
|
|
|
2023-01-30 01:52:40 -05:00
|
|
|
|
2024-12-19 10:14:11 -05:00
|
|
|
|
2019-01-10 15:49:54 +08:00
|
|
|
|
2022-03-15 08:51:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-13 15:09:37 +08:00
|
|
|
|
|
|
|
|
|
2022-03-15 08:51:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-12 11:49:19 -04:00
|
|
|
|
2024-03-18 11:54:13 +01:00
|
|
|
|
|
|
|
|
|
2022-03-15 08:51:24 +01:00
|
|
|
|
2020-10-08 15:46:38 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-30 11:38:35 -05:00
|
|
|
|
|
|
|
|
|
2024-05-06 17:59:55 +01:00
|
|
|
|
|
|
|
|
|
2022-03-15 15:27:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-02 14:55:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-09 10:40:06 +02:00
|
|
|
|
2022-11-02 14:55:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-15 15:27:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-02 16:55:31 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 10:54:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-18 11:43:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 10:54:38 -04:00
|
|
|
|
2025-06-17 09:49:45 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-16 09:49:33 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-28 15:41:50 +02:00
|
|
|
|