[PATCH][RFC] Allow explicit shrinking of arena heaps using an environment variable

[KOSAKI Motohiro]

>> > The choices are not mmap(MAP_FIXED) vs madvise(MADV_DONTNEED). They
>> > are mmap(MAP_FIXED) vs madvise(MADV_DONTNEED) followed by
>> > mprotect(PROT_NONE).
>>
>> If PROT_NONE is must one, I don't see any reason to don't take
>> mmap(MAP_FIXED).
>>
>> but..
>> Why do we need PROT_NONE? just for /proc/maps?
>
> I think this is about the third or forth time I've explained it now.
> PROT_NONE is needed to actually free the memory for other processes to
> use. MADV_DONTNEED frees the physical memory (eliminates dirty pages
> and thus prevents costly swapping of worthless data), but it does not
> free the commit charge because the pages are still potentially
> writable and thus not permanently backed by the zero page even though
> they initially just reference it.

I don't have any knowledge of hurd. then I'd like to explain Linux behavior.
On Linux, both MADV_DONTNEED and mprotect don't decommit virtual memory charge.
Only munmap (included implicit munmap by MAP_FIXED) makes decommit.

As far as I know, this behavior has 10+ years history.


see below comment in linux/mm/mprotect.c
------------------------------------
int
mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev,
	unsigned long start, unsigned long end, unsigned long newflags)
{
 (snip)
	/*
	 * If we make a private mapping writable we increase our commit;
	 * but (without finer accounting) cannot reduce our commit if we
	 * make it unwritable again. hugetlb mapping were accounted for
	 * even if read-only so there is no need to account for them here
	 */
	if (newflags & VM_WRITE) {
		if (!(oldflags & (VM_ACCOUNT|VM_WRITE|VM_HUGETLB|
						VM_SHARED|VM_NORESERVE))) {
			charged = nrpages;
			if (security_vm_enough_memory_mm(mm, charged))
				return -ENOMEM;
			newflags |= VM_ACCOUNT;
		}
	}