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

[Steven Price]

On 06/05/2026 16:43, Nicolas Frattaroli wrote:
> 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.

Thanks, it would be good to have a better understanding of why GPU
memory is special (and needs to be paged out) and the process' other
memory can be kept.

>>
>>> 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.

Yes the memory should be brought back in as soon as a job is submitted.
I've no particular workloads in mind - but it would be nice to be able
to point to something that actually improves by adding this feature.

> 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.

We don't want to be faulting memory in a page at a time for exactly the
reasons you state. So even if we do make things more fine-grained we're
going to have to implement some form of read-ahead. Otherwise it's
"powerpoint time" after any even that causes memory pressure.

A possible justification is if the system can tell an application is
about to be used and can "pre-fault" things before rendering starts. But
it's a rare system design where it has this form of precognition.

Thanks,
Steve

>>
>> 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>
>>>
>>
>>
> 
> 
> 
>