process_madvise() can make one Linux process request memory-management action for virtual-address ranges owned by another process. The target is identified by a pidfd, while an iovec array names the target ranges. This separates memory-policy decisions from the process whose mappings receive the advice.

The interface is useful for controllers that already have external knowledge about workload state. A runtime manager can mark inactive memory cold or request page reclamation without injecting code into the managed process. That capability is bounded by permission checks, supported advice values, and partial-progress semantics.

The address ranges belong to the target process

The call has this form on current glibc systems:

#include <sys/mman.h>
#include <sys/uio.h>

ssize_t process_madvise(int pidfd,
                        const struct iovec iovec[],
                        size_t n,
                        int advice,
                        unsigned int flags);

pidfd identifies the process receiving the advice. Each iov_base is interpreted as a virtual address in that process, not in the caller. The vector form allows one operation to describe multiple disjoint ranges.

The descriptor identity also avoids treating a reusable numeric PID as the sole target reference. Process lifetime and address-space validity still matter: a range can disappear or change as the target modifies its mappings.

flags is reserved and currently must be zero.

Cross-process advice is deliberately restricted

For another process, process_madvise() accepts a restricted set of advice operations. Current Linux documentation lists MADV_COLD, MADV_COLLAPSE, MADV_PAGEOUT, and MADV_WILLNEED. Since Linux 6.13, a process applying the call to itself may use any advice accepted by madvise().

The reclaim-oriented operations have materially different effects:

  • MADV_COLD deactivates applicable pages, making them more likely reclaim candidates under memory pressure. It is nondestructive and may be ignored for pages where it does not apply.
  • MADV_PAGEOUT requests reclamation of applicable pages. Anonymous pages can be swapped out; dirty file-backed pages can require writeback to backing storage.
  • MADV_WILLNEED signals expected near-term access and can trigger implementation-dependent preparation such as read-ahead.
  • MADV_COLLAPSE requests a best-effort synchronous collapse into Transparent Huge Pages where mapping and alignment constraints permit it.

These operations are requests to the memory subsystem, not durable ownership transfers or fixed future placement guarantees. In particular, advice that affects current page state does not freeze subsequent faults, accesses, or mapping changes.

Permission is part of the mechanism

Cross-process memory control is not granted merely because a caller can obtain a numeric PID. Linux applies access checks to the target process, and reclaim-style advice carries capability requirements. The documented interface requires appropriate access to the target address space; operations with performance impact require CAP_SYS_NICE where specified by the kernel interface.

This makes process_madvise() suitable for privileged service managers, container infrastructure, and memory controllers only when their authority model explicitly permits such intervention. It is not a general channel for arbitrary processes to evict each other’s pages.

Support is also conditional on the kernel configuration option CONFIG_ADVISE_SYSCALLS. Software that depends on the interface therefore needs to treat syscall availability as a runtime property rather than assuming it from headers alone.

A successful return can represent partial progress

The return value is a byte count, not simply a Boolean success marker. Linux may process some iovec elements and then encounter an error. In that case, a successful return can be smaller than the sum of all requested lengths.

For ranges with lengths (L_1, L_2, \ldots, L_n), the requested byte count is:

[ B = \sum_{i=1}^{n} L_i ]

A caller that receives 0 <= result < B has a partial operation and must not report the entire vector as advised.

This matters for external memory controllers because target mappings are not static transactions. Validation and application can encounter state that differs across vector elements, so accounting must follow the returned byte count.

Reclamation policy remains separate from mapping ownership

process_madvise() does not give the controller ownership of the target mapping. The target can continue reading, writing, faulting pages back in, unmapping regions, or replacing mappings according to its own synchronization and application logic.

That boundary is central to the interface: one process can influence memory-management treatment while the other retains its virtual address space and execution state. The kernel mediates the operation through a pidfd, explicit address ranges, advice-specific rules, and access checks.

The result is a narrow control surface for external memory policy. It can shift reclaim pressure or page state at selected ranges, but it does not turn those ranges into stable resources controlled by the advising process.

References

Linux Memory Management System Calls Processes