Re: [PATCH 0/4] Let userspace explicitly trigger memory reclaims

[Nicolas Frattaroli]

On Wednesday, 6 May 2026 17:06:56 Central European Summer Time Steven Price wrote:
> On 06/05/2026 11:45, Nicolas Frattaroli wrote:
> > RAM is not, in fact, cheap. Especially on embedded systems with a low
> > amount of memory, but known and well-defined userspace, more explicit
> > resource management can lead to better utilisation patterns. As an
> > example, a resource manager process on a purpose-built device may wish
> > to launch, and then explicitly swap out, memory of processes that are
> > kept "warm", to improve perceived startup latency of individual
> > full-screen applications without making the kernel figure out the usage
> > pattern from observation alone in order to swap out the right pages.
> 
> Have you considered memory control groups (memcg) for this purpose?
> Imposing a lower limit than currently allocated should trigger reclaim,
> so 'background' applications could have the limit lowered and then
> restored when moved to the foreground.

This is a suggestion in line with what I've made to the entity for
whom I am adding this, but was told that for them they really do want
tight control without having to use cgroups into technically doing it
by dynamically adjusting the limits of them.

I do think that writing 0 to `memory.high` to swap it out and `"max"`
to allow it to swap back in might work, though that'll then apply to
all of the process' memory, not just the GPU resources.

I will ask for clarification internally.

> 
> > To allow for this explicit control in the context of panthor's GPU
> > memory, add two new sysfs knobs. The first, mem_reclaim, runs an
> > explicit priv BO reclaim cycle on the TGID written to it.
> > 
> > The second, mem_claim, does the opposite: it swaps BOs back into active
> > memory.
> 
> How necessary is this mem_claim for performance? Have you done any
> benchmarking of explicitly claiming vs just allowing it to happen
> naturally? My gut feeling is that mem_claim should be unnecessary in
> most situations, but I'm prepared to be proved wrong.

I've done no benchmarking, but can do so if you have any preferred
workloads for this. Since we have to keep entire groups either in
memory or out of memory right now AFAIK, I don't expect this to be
very beneficial at all. At most we avoid a single fault I think.

I can drop the mem_claim part, though it may become relevant if we
ever have more fine-grained memory eviction where a single job or
group can run into multiple faults before everything it needs to
render a new frame is back in memory. In that case, it will be
beneficial, because it avoids doing the swap-in dance several
times while the user wonders why the UI is rendering at powerpoint
speeds as it touches memory pages that are still swapped out during
subsequent frames.

> 
> I'm not saying this series is necessarily the wrong approach - but I
> think we need a bit more justification for adding a new API for this.
> 
> Thanks,
> Steve

Kind regards,
Nicolas Frattaroli

> 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@xxxxxxxxxxxxx>
> > ---
> > Nicolas Frattaroli (4):
> >       drm/panthor: Add freed_sz parameter to reclaim_priv_bos
> >       MAINTAINERS: Add sysfs ABI docs to list of panthor files
> >       drm/panthor: Add explicit memory reclaim sysfs knob
> >       drm/panthor: Add explicit memory claim sysfs knob
> > 
> >  Documentation/ABI/testing/sysfs-driver-panthor-mem | 34 ++++++++
> >  MAINTAINERS                                        |  1 +
> >  drivers/gpu/drm/panthor/panthor_drv.c              | 93 ++++++++++++++++++++++
> >  drivers/gpu/drm/panthor/panthor_gem.c              |  7 +-
> >  drivers/gpu/drm/panthor/panthor_gem.h              |  1 +
> >  drivers/gpu/drm/panthor/panthor_mmu.c              | 70 +++++++++++++++-
> >  drivers/gpu/drm/panthor/panthor_mmu.h              |  4 +
> >  7 files changed, 205 insertions(+), 5 deletions(-)
> > ---
> > base-commit: 2c4b906cd135bbb44855287d0d0eff0ee0b47afe
> > change-id: 20260506-panthor-explicit-reclaim-3dffed028d8c
> > 
> > Best regards,
> > --  
> > Nicolas Frattaroli <nicolas.frattaroli@xxxxxxxxxxxxx>
> > 
> 
>