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

On Wed, Nov 04, 2026 at 09:13:28PM +0100, Thomas Hellström wrote:
> 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>

Reviewed-by: Matthew Brost <matthew.brost@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-05 23:14 UTC|newest]

Thread overview: 16+ 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 ` [PATCH 1/4] drm/ttm: Don't mark backed-up shmem folios accessed Thomas Hellström
2026-11-05 23:14   ` Matthew Brost [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
     [not found]   ` <UT7TwVbFQeWC9z3ZsJ5EGg@pixelcluster.dev>
2026-11-06  9:31     ` Natalie Vock
2026-11-10  8:37       ` Thomas Hellström
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
2026-11-05 20:05 ` ✓ Xe.CI.FULL: " 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=au0N17/xdm849qvT@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@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=nat@pixelcluster.dev \
    --cc=niranjana.vishwanathapura@intel.com \
    --cc=thomas.hellstrom@linux.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.