From: Boris Brezillon <boris.brezillon@collabora.com>
To: Nicolas Frattaroli <nicolas.frattaroli@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 18:17:35 +0200 [thread overview]
Message-ID: <20260420181735.2990999e@fedora> (raw)
In-Reply-To: <20260420-panthor-bo-reclaim-observability-v1-2-a4d1a36ee84f@collabora.com>
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?
> +
> 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.
> +
> 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.
>
next prev parent reply other threads:[~2026-04-20 16:17 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 [this message]
2026-04-20 17:46 ` Nicolas Frattaroli
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=20260420181735.2990999e@fedora \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.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=nicolas.frattaroli@collabora.com \
--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.