Conversation

Vlastimil Babka

STOP DOING VMA_MERGE()

VIRTUAL MEMORY AREAS WERE SUPPOSED TO REMAIN SEPARATE

YEARS OF MERGING yet NO REAL-WORLD USE FOUND trying to limit process vma count to less than your FINGERS

Wanted to go lower anyway for a laugh? We had a sysctl for that: It was called "vm.max_map_count"

"Can we merge the PREDECESSOR?" "Can we merge the SUCCESSOR?" "Can we merge BOTH the PREDECESSOR and the SUCCESSOR?" - Statements dreamed up by the utterly Deranged.

LOOK at what the mremap(), brk() and mprotect() has been demanding your Support for all this time, with all the 8 different cases of merging we built for them.
(This is REAL Code, done by REAL Kernel developers).

if (addr == prev->vm_end && mpol_equal(vma_policy(prev), policy) ?????
&& can_vma_merge_after(prev, vm_flags, anon_vma, file,
pgoff, vm_userfaultfd_ctx, anon_name)) { ???????
merge_prev = true; ?????????????????

"Hello, I would like PPPPCCCCNNNN to become PPPPNNNNNNNN please"

They have played us for absolute fools

https://lore.kernel.org/linux-mm/20240401192623.18575-2-vbabka@suse.cz/T/#u
1
8
15

@vbabka It's 01.04, I open https://lore.kernel.org/lkml/?q=babka, and it never disappoints

1
1
1
@oleksandr thanks, tbh this was a very late inspiration thanks to @ljs mentioning he would work on vma_merge() again. I saved him from that work now!
0
2
1