AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
>>>
>>
> 


  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