From: Patchwork <patchwork@emeril.freedesktop.org>
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: ✗ CI.checkpatch: warning for TTM shrinker fragmentation / partial restore fixes
Date: Tue, 05 May 2026 04:09:32 -0000 [thread overview]
Message-ID: <177795417249.37859.17808477124440593698@5ab824fced77> (raw)
In-Reply-To: <20260505033013.3266938-1-matthew.brost@intel.com>
== Series Details ==
Series: TTM shrinker fragmentation / partial restore fixes
URL : https://patchwork.freedesktop.org/series/165948/
State : warning
== Summary ==
+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
c8c12e558adaef7a4d125d83b6e1f8824bc13b82
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 5eec26fa2a50ee3cd3604f1cc1918d4e48568a70
Author: Matthew Brost <matthew.brost@intel.com>
Date: Mon May 4 20:30:13 2026 -0700
drm/ttm/pool: back up at native page order
ttm_pool_split_for_swap() splits high-order pool pages into order-0
pages during backup so each 4K page can be released to the system as
soon as it has been written to shmem. While this minimizes the
allocator's working set during reclaim, it actively fragments memory:
every TTM-backed compound page that the shrinker touches is shattered
into order-0 pages, even when the rest of the system would prefer that
the high-order block stay intact. Under sustained kswapd pressure this
is enough to drive other parts of MM into recovery loops from which
they cannot easily escape, because the memory TTM just freed is no
longer contiguous.
Stop unconditionally splitting on the backup path and back up each
compound at its native order in ttm_pool_backup():
- For each non-handle slot, read the order from the head page and
back up all 1<<order subpages to consecutive shmem indices,
writing the resulting handles into tt->pages[] as we go.
- On success, the compound is freed once at its native order. No
split_page(), no per-4K refcount juggling, no fragmentation
introduced from this path.
- Slots that already hold a backup handle from a previous partial
attempt are skipped. A compound that would extend past a
fault-injection-truncated num_pages is skipped rather than split.
A per-subpage backup failure cannot be made fully atomic: backing up a
subpage allocates a shmem folio before the source page can be released,
so under true OOM any subpage in a compound (not just the first) may
fail to be backed up with the rest of the source compound still live
and contiguous. To make forward progress in that case, fall back to
splitting the source compound and backing up its remaining subpages
individually:
- On the first per-subpage failure for a compound (and only if
order > 0), call ttm_pool_split_for_swap() to split the source
compound, release the subpages whose contents already live in
shmem (their handles in tt->pages stay valid), and retry the
failing subpage at order 0.
- Subsequent successful subpage backups in the now-split compound
free their source page individually as soon as the handle is
written.
- A second failure after splitting terminates the loop with partial
progress; the remaining order-0 subpages stay in tt->pages as
plain page pointers and are cleaned up by the normal
ttm_pool_drop_backed_up() / ttm_pool_free_range() paths.
This restores the original split-on-OOM fallback behavior while
keeping the common, non-OOM case fragmentation-free. It also
preserves the "partial backup is allowed" contract: shrunken is
incremented per backed-up subpage so the caller still sees forward
progress when a compound only partially succeeds.
The restore-side leftover-page branch in ttm_pool_restore_commit() is
left as-is for now: that path can still split a previously-retained
compound, but in practice it is unreachable under realistic workloads
(per profiling we have not been able to trigger it), so it is not
worth complicating the restore state machine to avoid the split there.
If it ever becomes a problem in practice it can be addressed
independently.
ttm_pool_split_for_swap() itself is retained both for the OOM
fallback above and for the restore path's remaining caller. The
DMA-mapped pre-backup unmap loop, the purge path, ttm_pool_free_*,
and ttm_pool_unmap_and_free() already operate at native order and
are unchanged.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages")
Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
+ /mt/dim checkpatch 94d56a898a2db27f841b17f6966a81ba502fe63c drm-intel
857b6fc8ac5a drm/ttm: Drop tt->restore after successful restore
-:18: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#18:
20545 [ 309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490
total: 0 errors, 1 warnings, 0 checks, 35 lines checked
5eec26fa2a50 drm/ttm/pool: back up at native page order
next prev parent reply other threads:[~2026-05-05 4:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 3:30 [PATCH v4 0/2] TTM shrinker fragmentation / partial restore fixes Matthew Brost
2026-05-05 3:30 ` [PATCH v4 1/2] drm/ttm: Drop tt->restore after successful restore Matthew Brost
2026-05-05 7:04 ` Thomas Hellström
2026-05-05 17:35 ` Matthew Brost
2026-05-05 3:30 ` [PATCH v4 2/2] drm/ttm/pool: back up at native page order Matthew Brost
2026-05-05 9:02 ` Thomas Hellström
2026-05-05 17:36 ` Matthew Brost
2026-05-05 4:09 ` Patchwork [this message]
2026-05-05 4:10 ` ✓ CI.KUnit: success for TTM shrinker fragmentation / partial restore fixes Patchwork
2026-05-05 4:59 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-05 10:46 ` ✗ Xe.CI.FULL: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-05-05 20:04 [PATCH v5 0/2] " Matthew Brost
2026-05-05 20:19 ` ✗ CI.checkpatch: warning for " Patchwork
2026-05-05 3:14 [PATCH v3 0/2] " Matthew Brost
2026-05-05 3:19 ` ✗ CI.checkpatch: warning for " Patchwork
2026-05-04 23:29 [PATCH v2 0/2] " Matthew Brost
2026-05-04 23:34 ` ✗ CI.checkpatch: warning for " Patchwork
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=177795417249.37859.17808477124440593698@5ab824fced77 \
--to=patchwork@emeril.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).