Re: [PATCH] mm: add Adaptive Memory Pressure Signaling (AMPRESS)

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

NAK.

This is a super questionable conceptual idea that isn't appropriate to submit as
a non-RFC patch.

I'm with David on this.

On Mon, Mar 02, 2026 at 12:45:33AM -0300, Andre Ramos wrote:
> Introduce /dev/ampress, a bidirectional fd-based interface for
> cooperative memory reclaim between the kernel and userspace.

There's just absolutely no way we'd expose anything like this as a character
device.

>
> Userspace processes open /dev/ampress and block on read() to receive
> struct ampress_event notifications carrying a graduated urgency level
> (LOW/MEDIUM/HIGH/FATAL), the NUMA node of the pressure source, and a
> suggested reclaim target in KiB. After freeing memory the process
> issues AMPRESS_IOC_ACK to close the feedback loop.

This is really not how we want to expose kernel interfaces. This seems like a
hack you'd implement internally rather than something we'd consider having in
mainline.

You're also inserting some new lock acquisitions and a linked list waking up
some unlimited number of threads on a core reclaim path - no.

>
> The feature hooks into balance_pgdat() in mm/vmscan.c, mapping the
> kswapd scan priority to urgency bands:
>   priority 10-12 -> LOW
>   priority  7-9  -> MEDIUM
>   priority  4-6  -> HIGH
>   priority  1-3  -> FATAL
>
> ampress_notify() is IRQ-safe (read_lock_irqsave + spin_lock_irqsave,
> no allocations) so it can be called from any reclaim context.
> Per-subscriber events overwrite without queuing to prevent unbounded
> backlog. A debugfs trigger at /sys/kernel/debug/ampress/inject allows
> testing without real memory pressure.

This is far too little description, especially given you're submitting
everything as one patch (which is not how kernel development is done).

The patch doesn't deal with MGLRU, and feels like a 'let's hook into one
specific part of mm and just dump out information to a random place'.

You could reasonably obtain the same information from BPF no?

>
> New files:
>   include/uapi/linux/ampress.h   - UAPI structs and ioctl definitions
>   include/linux/ampress.h        - internal header and ampress_notify()
>   include/trace/events/ampress.h - tracepoints for notify and ack
>   mm/ampress.c                   - miscdevice driver and core logic
>   mm/ampress_test.c              - KUnit tests (3/3 passing)
>   tools/testing/ampress/         - userspace integration and stress tests

This doesn't belong in a commit message.

>
> Signed-off-by: André Castro Ramos <acastroramos1987@gmail.com>
> ---
>  MAINTAINERS                            |  11 +
>  include/linux/ampress.h                |  34 +++
>  include/trace/events/ampress.h         |  70 ++++++
>  include/uapi/linux/ampress.h           |  40 ++++
>  mm/Kconfig                             |  26 ++
>  mm/Makefile                            |   2 +
>  mm/ampress.c                           | 320 +++++++++++++++++++++++++
>  mm/ampress_test.c                      | 124 ++++++++++
>  mm/vmscan.c                            |  27 +++
>  tools/testing/ampress/.gitignore       |   2 +
>  tools/testing/ampress/Makefile         |  21 ++
>  tools/testing/ampress/ampress_stress.c | 199 +++++++++++++++
>  tools/testing/ampress/ampress_test.c   | 212 ++++++++++++++++
>  13 files changed, 1088 insertions(+)

This is not how you submit patches, this needed to be broken up into a series,
submitting a single patch changing 13 files and adding 1,088 lines isn't how
kernel development works.

>  create mode 100644 include/linux/ampress.h
>  create mode 100644 include/trace/events/ampress.h
>  create mode 100644 include/uapi/linux/ampress.h
>  create mode 100644 mm/ampress.c
>  create mode 100644 mm/ampress_test.c
>  create mode 100644 tools/testing/ampress/.gitignore
>  create mode 100644 tools/testing/ampress/Makefile
>  create mode 100644 tools/testing/ampress/ampress_stress.c
>  create mode 100644 tools/testing/ampress/ampress_test.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 61bf550fd37..ea4d7861ff9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16629,6 +16629,17 @@ F:    mm/memremap.c
>  F:    mm/memory_hotplug.c
>  F:    tools/testing/selftests/memory-hotplug/
>
> +ADAPTIVE MEMORY PRESSURE SIGNALING (AMPRESS)
> +M:    Darabat <playbadly1@gmail.com>
> +L:    linux-mm@kvack.org
> +S:    Maintained
> +F:    include/linux/ampress.h
> +F:    include/trace/events/ampress.h
> +F:    include/uapi/linux/ampress.h
> +F:    mm/ampress.c
> +F:    mm/ampress_test.c
> +F:    tools/testing/ampress/

As David said, it's really not proper to add yourself as a maintainer without a
track record in the kernel and community trust.

Maintainership is a serious responsibility and really requires that you have
both demonstrated consistent technical understanding and an ability to work with
the community.

Obviously as a new contributor, neither have been demonstrated.

Also there's an existing convention of 'MEMORY MANAGEMENT - xxx' for mm entries
in MAINTAINERS.

Thanks, Lorenzo