mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Thadeu Lima de Souza Cascardo" <cascardo@igalia.com>,
	"Michel Dänzer" <michel.daenzer@mailbox.org>,
	"Huang Rui" <ray.huang@amd.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kernel-dev@igalia.com,
	Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH RFC v2 0/3] drm/ttm: allow direct reclaim to be skipped
Date: Fri, 19 Sep 2025 08:43:34 +0100	[thread overview]
Message-ID: <67c83b24-01b6-4633-8645-52dc746c32e2@igalia.com> (raw)
In-Reply-To: <6f92ff06-04c3-440b-becb-50a7693ecc39@amd.com>


On 19/09/2025 07:46, Christian König wrote:
> On 18.09.25 22:09, Thadeu Lima de Souza Cascardo wrote:
>> On certain workloads, like on ChromeOS when opening multiple tabs and
>> windows, and switching desktops, memory pressure can build up and latency
>> is observed as high order allocations result in memory reclaim. This was
>> observed when running on an amdgpu.
>>
>> This is caused by TTM pool allocations and turning off direct reclaim when
>> doing those higher order allocations leads to lower memory pressure.
>>
>> Since turning direct reclaim off might also lead to lower throughput,
>> make it tunable, both as a module parameter that can be changed in sysfs
>> and as a flag when allocating a GEM object.
>>
>> A latency option will avoid direct reclaim for higher order allocations.
>>
>> The throughput option could be later used to more agressively compact pages
>> or reclaim, by not using __GFP_NORETRY.
> 
> Well I can only repeat it, at least for amdgpu that is a clear NAK from my side to this.
> 
> The behavior to allocate huge pages is a must have for the driver.

Disclaimer that I wouldn't go system-wide but per device - so somewhere 
in sysfs rather than a modparam. That kind of a toggle would not sound 
problematic to me since it leaves the policy outside the kernel and 
allows people to tune to their liking.

One side question thought - does AMD benefit from larger than 2MiB 
contiguous blocks? IIUC the maximum PTE is 2MiB so maybe not? In which 
case it may make sense to add some TTM API letting drivers tell the pool 
allocator what is the maximum order to bother with. Larger than that may 
have diminishing benefit for the disproportionate pressure on the memory 
allocator and reclaim.

Regards,

Tvrtko

> The alternative I can offer is to disable the fallback which in your case would trigger the OOM killer.
> 
> Regards,
> Christian.
> 
>>
>> Other drivers can later opt to use this mechanism too.
>>
>> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
>> ---
>> Changes in v2:
>> - Make disabling direct reclaim an option.
>> - Link to v1: https://lore.kernel.org/r/20250910-ttm_pool_no_direct_reclaim-v1-1-53b0fa7f80fa@igalia.com
>>
>> ---
>> Thadeu Lima de Souza Cascardo (3):
>>        ttm: pool: allow requests to prefer latency over throughput
>>        ttm: pool: add a module parameter to set latency preference
>>        drm/amdgpu: allow allocation preferences when creating GEM object
>>
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c    |  3 ++-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  3 ++-
>>   drivers/gpu/drm/ttm/ttm_pool.c             | 23 +++++++++++++++++------
>>   drivers/gpu/drm/ttm/ttm_tt.c               |  2 +-
>>   include/drm/ttm/ttm_bo.h                   |  5 +++++
>>   include/drm/ttm/ttm_pool.h                 |  2 +-
>>   include/drm/ttm/ttm_tt.h                   |  2 +-
>>   include/uapi/drm/amdgpu_drm.h              |  9 +++++++++
>>   8 files changed, 38 insertions(+), 11 deletions(-)
>> ---
>> base-commit: f83ec76bf285bea5727f478a68b894f5543ca76e
>> change-id: 20250909-ttm_pool_no_direct_reclaim-ee0807a2d3fe
>>
>> Best regards,
> 


  reply	other threads:[~2025-09-19  7:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 20:09 Thadeu Lima de Souza Cascardo
2025-09-18 20:09 ` [PATCH RFC v2 1/3] ttm: pool: allow requests to prefer latency over throughput Thadeu Lima de Souza Cascardo
2025-09-18 20:09 ` [PATCH RFC v2 2/3] ttm: pool: add a module parameter to set latency preference Thadeu Lima de Souza Cascardo
2025-09-18 20:09 ` [PATCH RFC v2 3/3] drm/amdgpu: allow allocation preferences when creating GEM object Thadeu Lima de Souza Cascardo
2025-09-19  6:46 ` [PATCH RFC v2 0/3] drm/ttm: allow direct reclaim to be skipped Christian König
2025-09-19  7:43   ` Tvrtko Ursulin [this message]
2025-09-19  8:01     ` Christian König
2025-09-19  8:46       ` Tvrtko Ursulin
2025-09-19 10:17         ` Christian König
2025-09-19 10:42           ` Tvrtko Ursulin
2025-09-19 12:04             ` Christian König
2025-09-19 11:13       ` Thadeu Lima de Souza Cascardo
2025-09-19 11:39         ` Christian König

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=67c83b24-01b6-4633-8645-52dc746c32e2@igalia.com \
    --to=tvrtko.ursulin@igalia.com \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=cascardo@igalia.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=michel.daenzer@mailbox.org \
    --cc=mripard@kernel.org \
    --cc=ray.huang@amd.com \
    --cc=senozhatsky@chromium.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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

all inboxes | Powered by JetHome®