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 <[email protected]> >>> --- >>> 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 <[email protected]> >>> >> >> > > > >
