From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
amd-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: kernel-dev@igalia.com, "Alex Deucher" <alexander.deucher@amd.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Dave Airlie" <airlied@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Lyude Paul" <lyude@redhat.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Sui Jingfeng" <suijingfeng@loongson.cn>,
"Thadeu Lima de Souza Cascardo" <cascardo@igalia.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Zack Rusin" <zack.rusin@broadcom.com>
Subject: Re: [PATCH v3 0/5] Improving the worst case TTM large allocation latency
Date: Wed, 8 Oct 2025 16:02:42 +0200 [thread overview]
Message-ID: <9bb3c06e-25c1-43d8-a4e8-e529c53ff77d@amd.com> (raw)
In-Reply-To: <22228578-a03c-4fc1-85b2-d281525a2b6f@igalia.com>
On 08.10.25 15:50, Tvrtko Ursulin wrote:
>
> On 08/10/2025 13:35, Christian König wrote:
>> On 08.10.25 13:53, Tvrtko Ursulin wrote:
>>> Disclaimer:
>>> Please note that as this series includes a patch which touches a good number of
>>> drivers I will only copy everyone in the cover letter and the respective patch.
>>> Assumption is people are subscribed to dri-devel so can look at the whole series
>>> there. I know someone is bound to complain for both the case when everyone is
>>> copied on everything for getting too much email, and also for this other case.
>>> So please be flexible.
>>>
>>> Description:
>>>
>>> All drivers which use the TTM pool allocator end up requesting large order
>>> allocations when allocating large buffers. Those can be slow due memory pressure
>>> and so add latency to buffer creation. But there is often also a size limit
>>> above which contiguous blocks do not bring any performance benefits. This series
>>> allows drivers to say when it is okay for the TTM to try a bit less hard.
>>>
>>> We do this by allowing drivers to specify this cut off point when creating the
>>> TTM device and pools. Allocations above this size will skip direct reclaim so
>>> under memory pressure worst case latency will improve. Background reclaim is
>>> still kicked off and both before and after the memory pressure all the TTM pool
>>> buckets remain to be used as they are today.
>>>
>>> This is especially interesting if someone has configured MAX_PAGE_ORDER to
>>> higher than the default. And even with the default, with amdgpu for example,
>>> the last patch in the series makes use of the new feature by telling TTM that
>>> above 2MiB we do not expect performance benefits. Which makes TTM not try direct
>>> reclaim for the top bucket (4MiB).
>>>
>>> End result is TTM drivers become a tiny bit nicer mm citizens and users benefit
>>> from better worst case buffer creation latencies. As a side benefit we get rid
>>> of two instances of those often very unreadable mutliple nameless booleans
>>> function signatures.
>>>
>>> If this sounds interesting and gets merge the invidual drivers can follow up
>>> with patches configuring their thresholds.
>>>
>>> v2:
>>> * Christian suggested to pass in the new data by changing the function signatures.
>>>
>>> v3:
>>> * Moved ttm pool helpers into new ttm_pool_internal.h. (Christian)
>>
>> Patch #3 is Acked-by: Christian König <christian.koenig@amd.com>.
>>
>> The rest is Reviewed-by: Christian König <christian.koenig@amd.com>
>
> Thank you!
>
> So I think now I need acks to merge via drm-misc for all the drivers which have their own trees. Which seems to be just xe.
I think you should ping the XE guys for their opinion, but since there shouldn't be any functional change for them you can probably go ahead and merge the patches to drm-misc-next when there is no reply in time.
> Also interesting for other drivers is that when this lands folks can start passing in their "max size which leads to performance gains" via TTM_POOL_BENEFICIAL_ORDER and get the worst case allocation latency improvements.
Yeah, as said before if any other driver says they don't need this behavior we should certainly add something.
> I am thinking xe also maxes out at 2MiB pages, for others I don't know.
For AMDGPU it can actually be that this changes on future HW generations, so having it configurable is certainly the right approach.
Regards,
Christian.
>
> Regards,
>
> Tvrtko
>
>>> v1 thread:
>>> https://lore.kernel.org/dri-devel/20250919131127.90932-1-tvrtko.ursulin@igalia.com/
>>>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Danilo Krummrich <dakr@kernel.org>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>>> Cc: Lyude Paul <lyude@redhat.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: Maxime Ripard <mripard@kernel.org>
>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> Cc: Sui Jingfeng <suijingfeng@loongson.cn>
>>> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Zack Rusin <zack.rusin@broadcom.com>
>>>
>>> Tvrtko Ursulin (5):
>>> drm/ttm: Add getter for some pool properties
>>> drm/ttm: Replace multiple booleans with flags in pool init
>>> drm/ttm: Replace multiple booleans with flags in device init
>>> drm/ttm: Allow drivers to specify maximum beneficial TTM pool size
>>> drm/amdgpu: Configure max beneficial TTM pool allocation order
>>>
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
>>> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
>>> drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
>>> drivers/gpu/drm/loongson/lsdc_ttm.c | 2 +-
>>> drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 +-
>>> drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
>>> drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-
>>> drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 16 +++----
>>> .../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 2 +-
>>> drivers/gpu/drm/ttm/tests/ttm_device_test.c | 31 +++++--------
>>> drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 22 ++++-----
>>> drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 7 +--
>>> drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 23 +++++-----
>>> drivers/gpu/drm/ttm/ttm_device.c | 7 ++-
>>> drivers/gpu/drm/ttm/ttm_pool.c | 45 +++++++++++--------
>>> drivers/gpu/drm/ttm/ttm_pool_internal.h | 24 ++++++++++
>>> drivers/gpu/drm/ttm/ttm_tt.c | 10 +++--
>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +-
>>> drivers/gpu/drm/xe/xe_device.c | 2 +-
>>> include/drm/ttm/ttm_device.h | 2 +-
>>> include/drm/ttm/ttm_pool.h | 13 +++---
>>> 21 files changed, 125 insertions(+), 106 deletions(-)
>>> create mode 100644 drivers/gpu/drm/ttm/ttm_pool_internal.h
>>>
>>
>
next prev parent reply other threads:[~2025-10-08 14:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 11:53 [PATCH v3 0/5] Improving the worst case TTM large allocation latency Tvrtko Ursulin
2025-10-08 11:53 ` [PATCH v3 1/5] drm/ttm: Add getter for some pool properties Tvrtko Ursulin
2025-10-08 11:53 ` [PATCH v3 2/5] drm/ttm: Replace multiple booleans with flags in pool init Tvrtko Ursulin
2025-10-10 15:10 ` kernel test robot
2025-10-08 11:53 ` [PATCH v3 3/5] drm/ttm: Replace multiple booleans with flags in device init Tvrtko Ursulin
2025-10-08 11:53 ` [PATCH v3 4/5] drm/ttm: Allow drivers to specify maximum beneficial TTM pool size Tvrtko Ursulin
2025-10-08 11:53 ` [PATCH v3 5/5] drm/amdgpu: Configure max beneficial TTM pool allocation order Tvrtko Ursulin
2025-10-08 23:18 ` Matthew Brost
2025-10-09 8:58 ` Tvrtko Ursulin
2025-10-10 14:14 ` Thomas Hellström
2025-10-13 7:03 ` Christian König
2025-10-08 12:35 ` [PATCH v3 0/5] Improving the worst case TTM large allocation latency Christian König
2025-10-08 13:50 ` Tvrtko Ursulin
2025-10-08 14:02 ` Christian König [this message]
2025-10-08 14:39 ` Thomas Hellström
2025-10-09 8:53 ` Tvrtko Ursulin
2025-10-10 14:11 ` Thomas Hellström
2025-10-10 14:18 ` Thomas Hellström
2025-10-11 8:00 ` Tvrtko Ursulin
2025-10-13 8:48 ` Thomas Hellström
2025-10-13 9:17 ` Tvrtko Ursulin
2025-10-13 9:23 ` Tvrtko Ursulin
2025-10-08 14:34 ` Matthew Auld
2025-10-09 8:41 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9bb3c06e-25c1-43d8-a4e8-e529c53ff77d@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=cascardo@igalia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kernel-dev@igalia.com \
--cc=kraxel@redhat.com \
--cc=lucas.demarchi@intel.com \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=suijingfeng@loongson.cn \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tvrtko.ursulin@igalia.com \
--cc=tzimmermann@suse.de \
--cc=zack.rusin@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.