All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Natalie Vock" <nat@pixelcluster.dev>,
	"Arun Pravin" <arunpravin.paneerselvam@amd.com>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Niranjana Vishwanathapura" <niranjana.vishwanathapura@intel.com>,
	dri-devel@lists.freedesktop.org
Subject: [PATCH 1/4] drm/ttm: Don't mark backed-up shmem folios accessed
Date: Wed,  4 Nov 2026 21:13:28 +0100	[thread overview]
Message-ID: <20261104201331.2462-2-thomas.hellstrom@linux.intel.com> (raw)
In-Reply-To: <20261104201331.2462-1-thomas.hellstrom@linux.intel.com>

ttm_backup_backup_folio() unconditionally called folio_mark_accessed()
on the freshly populated shmem folio before copying the BO's data into
it. This path is only reached from a shrinker, i.e. precisely when the
system has already decided it needs memory back, and the whole point
of backing a page up into shmem is to let core mm reclaim it through
the normal swap/writeback path instead of keeping it pinned as TTM
memory.

Marking the folio accessed works against that: it sets the referenced
bit / promotes the folio on the LRU, so a later reclaim scan gives it
a second chance (or skips it) instead of reclaiming it on sight. This
is actively counter-productive even when the writeback backup flag is
set to synchronously flush the folio's content via shmem_write_folio():
writeback only clears the dirty bit, it does not free the page, so an
accessed folio just sits there, clean and resident, protected from the
very reclaim pass it was written back for.

Drop the folio_mark_accessed() call so these folios decay through
normal LRU aging and become immediate reclaim candidates once written
back (or once picked up by the system's own asynchronous laundering),
instead of being artificially kept warm.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 drivers/gpu/drm/ttm/ttm_backup.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_backup.c b/drivers/gpu/drm/ttm/ttm_backup.c
index 0c2d53a13b2a..9589067ad8cf 100644
--- a/drivers/gpu/drm/ttm/ttm_backup.c
+++ b/drivers/gpu/drm/ttm/ttm_backup.c
@@ -149,7 +149,6 @@ ttm_backup_backup_folio(struct file *backup, struct folio *folio,
 		to_nr = min_t(int, nr_pages - i,
 			      folio_next_index(to_folio) - (idx + i));
 
-		folio_mark_accessed(to_folio);
 		folio_lock(to_folio);
 		folio_mark_dirty(to_folio);
 
-- 
2.56.0


  reply	other threads:[~2026-11-04 20:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 20:13 [PATCH 0/4] drm/ttm, drm/xe: Support partially backed-up ttm_tts Thomas Hellström
2026-11-04 20:13 ` Thomas Hellström [this message]
2026-11-04 20:13 ` [PATCH 2/4] drm/xe/bo: Pass page and tt counts to the shrinker account helpers Thomas Hellström
2026-11-04 20:13 ` [PATCH 3/4] drm/ttm, drm/xe: Introduce TTM_TT_FLAG_PARTIAL for partially backed-up tts Thomas Hellström
2026-11-04 20:47   ` sashiko-bot
2026-11-05  4:50   ` kernel test robot
2026-11-04 20:13 ` [PATCH 4/4] drm/ttm, drm/xe: Gate reserve-dipping backup retries on may_writeback Thomas Hellström
2026-11-04 20:41   ` sashiko-bot
2026-11-04 20:23 ` ✓ CI.KUnit: success for drm/ttm, drm/xe: Support partially backed-up ttm_tts Patchwork
2026-11-04 20:57 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-05  4:36 ` ✓ CI.KUnit: success for drm/ttm, drm/xe: Support partially backed-up ttm_tts (rev2) Patchwork
2026-11-05  5:13 ` ✓ Xe.CI.BAT: " 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=20261104201331.2462-2-thomas.hellstrom@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=nat@pixelcluster.dev \
    --cc=niranjana.vishwanathapura@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.