From: "Christian König" <christian.koenig@amd.com>
To: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>,
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: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
kernel-dev@igalia.com,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH] drm: ttm: do not direct reclaim when allocating high order pages
Date: Wed, 10 Sep 2025 14:11:58 +0200 [thread overview]
Message-ID: <e79a134b-89de-4da1-b64b-b890227fce8a@amd.com> (raw)
In-Reply-To: <20250910-ttm_pool_no_direct_reclaim-v1-1-53b0fa7f80fa@igalia.com>
On 10.09.25 13:59, Thadeu Lima de Souza Cascardo wrote:
> When the TTM pool tries to allocate new pages, it stats with max order. If
> there are no pages ready in the system, the page allocator will start
> reclaim. If direct reclaim fails, the allocator will reduce the order until
> it gets all the pages it wants with whatever order the allocator succeeds
> to reclaim.
>
> However, while the allocator is reclaiming, lower order pages might be
> available, which would work just fine for the pool allocator. Doing direct
> reclaim just introduces latency in allocating memory.
>
> The system should still start reclaiming in the background with kswapd, but
> the pool allocator should try to allocate a lower order page instead of
> directly reclaiming.
>
> If not even a order-1 page is available, the TTM pool allocator will
> eventually get to start allocating order-0 pages, at which point it should
> and will directly reclaim.
Yeah that was discussed before quite a bit but at least for AMD GPUs that is absolutely not something we should do.
The performance difference between using high and low order pages can be up to 30%. So the added extra latency is just vital for good performance.
We could of course make that depend on the HW you use if it isn't necessary for some other GPU, but at least both NVidia and Intel seem to have pretty much the same HW restrictions.
NVidia has been working on extending this to even use 1GiB pages to reduce the TLB overhead even further.
Regards,
Christian.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index baf27c70a4193a121fbc8b4e67cd6feb4c612b85..6124a53cd15634c833bce379093b557d2a2660fd 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -144,9 +144,11 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,
> * Mapping pages directly into an userspace process and calling
> * put_page() on a TTM allocated page is illegal.
> */
> - if (order)
> + if (order) {
> gfp_flags |= __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_NOWARN |
> __GFP_THISNODE;
> + gfp_flags &= ~__GFP_DIRECT_RECLAIM;
> + }
>
> if (!pool->use_dma_alloc) {
> p = alloc_pages_node(pool->nid, gfp_flags, order);
>
> ---
> base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0
> change-id: 20250909-ttm_pool_no_direct_reclaim-ee0807a2d3fe
>
> Best regards,
next prev parent reply other threads:[~2025-09-10 12:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 11:59 [PATCH] drm: ttm: do not direct reclaim when allocating high order pages Thadeu Lima de Souza Cascardo
2025-09-10 12:11 ` Christian König [this message]
2025-09-10 12:52 ` Thadeu Lima de Souza Cascardo
2025-09-10 13:34 ` Christian König
2025-09-11 8:26 ` Michel Dänzer
2025-09-11 9:07 ` Christian König
2025-09-11 12:49 ` Michel Dänzer
2025-09-11 14:31 ` Christian König
2025-09-11 14:48 ` Michel Dänzer
2025-09-11 16:09 ` 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=e79a134b-89de-4da1-b64b-b890227fce8a@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=cascardo@igalia.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=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