On 13/02/2026 13:47, Ashutosh Bapat wrote:
`man madvise` has this MADV_REMOVE (since Linux 2.6.16) Free up a given range of pages and its associated backing store. This is equivalent to punching a hole in the corresponding byte range of the backing store (see fallocate(2)). Subsequent accesses in the specified address range will see bytes containing zero.The specified address range must be mapped shared and writable. This flag cannot be applied to locked pages, Huge TLB pages, or VM_PFNMAP pages. In the initial implementation, only tmpfs(5) was supported MADV_REMOVE; but since Linux 3.5, any filesystem which supports the fallocate(2) FALLOC_FL_PUNCH_HOLE mode also supports MADV_REMOVE. Hugetlbfs fails with the error EINVAL and other filesystems fail with the error EOPNOTSUPP. It says the flag can not be applied to Huge TLB pages. We won't be able to make resizable shared memory structures allocated with huge pages. That seems like a serious restriction.
Per https://man7.org/linux/man-pages/man2/madvise.2.html: MADV_REMOVE (since Linux 2.6.16) ... Support for the Huge TLB filesystem was added in Linux v4.3.
I may be misunderstanding something, but it seems like this is useful to free already allocated memory, not necessarily allocate more memory. I don't understand how a user would start with a larger reserved address space with only small portions of that space being backed by memory.
Hmm, I guess you'll need to use MAP_NORESERVE in the first mmap() call. to reserve address space for the maximum size, and then madvise(MADV_POPULATE_WRITE) using the initial size. Later, madvise(MADV_REMOVE) to shrink, and madvise(MADV_POPULATE_WRITE) to grow again.
- Heikki
