AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
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>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Lyude Paul" <lyude@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"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 14:35:58 +0200	[thread overview]
Message-ID: <6bba6d25-91f3-49a6-81fc-7a03d891cd1d@amd.com> (raw)
In-Reply-To: <20251008115314.55438-1-tvrtko.ursulin@igalia.com>

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>

Thanks,
Christian.

> 
> 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 12:36 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 ` Christian König [this message]
2025-10-08 13:50   ` [PATCH v3 0/5] Improving the worst case TTM large allocation latency 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
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=6bba6d25-91f3-49a6-81fc-7a03d891cd1d@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox