All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: 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>,
	Steven Price <steven.price@arm.com>,
	Liviu Dudau <liviu.dudau@arm.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCH 2/2] drm/panthor: Implement evicted status for GEM objects
Date: Mon, 20 Apr 2026 19:46:52 +0200	[thread overview]
Message-ID: <ArK2sKSOQ3qNB7BnrfkXew@collabora.com> (raw)
In-Reply-To: <20260420181735.2990999e@fedora>

On Monday, 20 April 2026 18:17:35 Central European Summer Time Boris Brezillon wrote:
> On Mon, 20 Apr 2026 17:47:00 +0200
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> 
> > For fdinfo to be able to fill its evicted counter with data, panthor
> > needs to keep track of whether a GEM object has ever been reclaimed.
> > Just checking whether the pages are resident isn't enough, as newly
> > allocated objects also won't be resident.
> > 
> > Do this with a new atomic_t member on panthor_gem_object. It's increased
> > when an object gets evicted by the shrinker. While it's allowed to wrap
> > around to below zero and assume a value less than a previous observed
> > value, the reclaim counter will never return to 0 for any particular
> > object once it's been reclaimed at least once.
> > 
> > Use this new member to then set the appropriate DRM_GEM_OBJECT_EVICTED
> > status flag for fdinfo, and use it in the gems debugfs. It's possible to
> > distinguish evicted non-resident pages from newly allocated non-resident
> > pages by checking whether reclaimed_count is != 0.
> > 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >  drivers/gpu/drm/panthor/panthor_gem.c | 10 ++++++++++
> >  drivers/gpu/drm/panthor/panthor_gem.h | 11 +++++++++++
> >  2 files changed, 21 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> > index 69cef05b6ef7..4b761b39565d 100644
> > --- a/drivers/gpu/drm/panthor/panthor_gem.c
> > +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> > @@ -687,6 +687,10 @@ static void panthor_gem_evict_locked(struct panthor_gem_object *bo)
> >  	if (drm_WARN_ON_ONCE(bo->base.dev, !bo->backing.pages))
> >  		return;
> >  
> > +	/* Don't ever wrap around as far as 0, jump from INT_MIN to 1 */
> > +	if (!atomic_inc_unless_negative(&bo->reclaimed_count))
> > +		atomic_set(&bo->reclaimed_count, 1);
> 
> Can't we just go
> 
> 	atomic_add_unless(&bo->reclaimed_count, 1, INT_MAX);
> 
> here, to handle the INT_MAX saturation?

Yeah, I was torn between the two. My way does keep a somewhat
cyclical nature, so once it wraps, things could still detect
that it's increasing from one observance to the next.

But now that I think about it again, it's not a property of this
count that's worth keeping, I think. Nothing relies on this
behaviour currently, and at best it'll trip up any code that uses
it for a < comparison later down the road.

> > +
> >  	panthor_gem_dev_map_cleanup_locked(bo);
> >  	panthor_gem_backing_cleanup_locked(bo);
> >  	panthor_gem_update_reclaim_state_locked(bo, NULL);
> > @@ -788,6 +792,8 @@ static enum drm_gem_object_status panthor_gem_status(struct drm_gem_object *obj)
> >  
> >  	if (drm_gem_is_imported(&bo->base) || bo->backing.pages)
> >  		res |= DRM_GEM_OBJECT_RESIDENT;
> > +	else if (atomic_read(&bo->reclaimed_count))
> > +		res |= DRM_GEM_OBJECT_EVICTED;
> >  
> >  	return res;
> >  }
> > @@ -1595,6 +1601,7 @@ static void panthor_gem_debugfs_print_flag_names(struct seq_file *m)
> >  	static const char * const gem_state_flags_names[] = {
> >  		[PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT] = "imported",
> >  		[PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT] = "exported",
> > +		[PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT] = "evicted",
> >  	};
> >  
> >  	static const char * const gem_usage_flags_names[] = {
> > @@ -1648,6 +1655,9 @@ static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo,
> >  
> >  	if (drm_gem_is_imported(&bo->base))
> >  		gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED;
> > +	else if (!resident_size && atomic_read(&bo->reclaimed_count))
> > +		gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED;
> 
> I think it'd be interesting to know the number of times a BO got
> evicted.

Agreed. Should I add that as a separate column? I think I'll keep the
state flag even if I add a column, because even if it's technically
redundant, it'll still be useful to see without having to compare
three different columns.

> > +
> >  	if (bo->base.dma_buf)
> >  		gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED;
> >  
> > diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h
> > index ae0491d0b121..1ab573f03330 100644
> > --- a/drivers/gpu/drm/panthor/panthor_gem.h
> > +++ b/drivers/gpu/drm/panthor/panthor_gem.h
> > @@ -19,12 +19,16 @@ struct panthor_vm;
> >  enum panthor_debugfs_gem_state_flags {
> >  	PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT = 0,
> >  	PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT = 1,
> > +	PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT = 2,
> >  
> >  	/** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED: GEM BO is PRIME imported. */
> >  	PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT),
> >  
> >  	/** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED: GEM BO is PRIME exported. */
> >  	PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT),
> > +
> > +	/** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED: GEM BO is evicted to swap. */
> > +	PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT),
> >  };
> >  
> >  enum panthor_debugfs_gem_usage_flags {
> > @@ -172,6 +176,13 @@ struct panthor_gem_object {
> >  	/** @reclaim_state: Cached reclaim state */
> >  	enum panthor_gem_reclaim_state reclaim_state;
> >  
> > +	/**
> > +	 * @reclaimed_count: How many times object has been evicted to swap.
> 
> 	 *
> 
> > +	 * Never returns to 0 once incremented even on wrap-around, but may
> > +	 * become < 0 and < the previous value if wrap-around occurs.
> 
> With the saturation I suggested, I'd just add that when INT_MAX is
> reached, it will stay there.
> 
> > +	 */
> > +	atomic_t reclaimed_count;
> > +
> >  	/**
> >  	 * @exclusive_vm_root_gem: Root GEM of the exclusive VM this GEM object
> >  	 * is attached to.
> > 
> 
> 





  reply	other threads:[~2026-04-20 17:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 15:46 [PATCH 0/2] Let userspace know about swapped out panthor GEM objects Nicolas Frattaroli
2026-04-20 15:46 ` [PATCH 1/2] drm/fdinfo: Add "evicted" memory accounting Nicolas Frattaroli
2026-04-20 15:47 ` [PATCH 2/2] drm/panthor: Implement evicted status for GEM objects Nicolas Frattaroli
2026-04-20 16:17   ` Boris Brezillon
2026-04-20 17:46     ` Nicolas Frattaroli [this message]
2026-04-21  7:22       ` Boris Brezillon

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=ArK2sKSOQ3qNB7BnrfkXew@collabora.com \
    --to=nicolas.frattaroli@collabora.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --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 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.