From: Matthew Auld <matthew.auld@intel.com>
To: "Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"Christian König" <christian.koenig@amd.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 15:34:40 +0100 [thread overview]
Message-ID: <fe98edc2-cc18-4c44-a4cb-5c41b60834e6@intel.com> (raw)
In-Reply-To: <22228578-a03c-4fc1-85b2-d281525a2b6f@igalia.com>
On 08/10/2025 14: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.
>
> 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.
>
> I am thinking xe also maxes out at 2MiB pages, for others I don't know.
Yeah, next level up from 2M GTT page is still 1G GTT page. I think we
especially need 64K/2M system memory pages on igpu to get some perf back
when enabling iommu on some platforms IIRC. Not aware of really needing
> 2M so sounds like we might also benefit by maxing out at 2M, if it
reduces allocation latency in some cases.
>
> 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:34 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
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 [this message]
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=fe98edc2-cc18-4c44-a4cb-5c41b60834e6@intel.com \
--to=matthew.auld@intel.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=cascardo@igalia.com \
--cc=christian.koenig@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox