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.
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'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
Signed-off-by: Nicolas Frattaroli nicolas.frattaroli@collabora.com
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@collabora.com
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@collabora.com
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@collabora.com
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@collabora.com
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@collabora.com
linaro-mm-sig@lists.linaro.org
-
Nicolas Frattaroli -
Steven Price