linux-kernel - Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <08ace5ea-ca09-4506-8ebd-016e8061c51b@redhat.com>
Date: Tue, 24 Jun 2025 14:05:56 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Pedro Falcato <pfalcato@...e.de>,
 Andrew Morton <akpm@...ux-foundation.org>, Vlastimil Babka <vbabka@...e.cz>,
 Jann Horn <jannh@...gle.com>, "Liam R . Howlett" <Liam.Howlett@...cle.com>,
 Suren Baghdasaryan <surenb@...gle.com>, Matthew Wilcox
 <willy@...radead.org>, Rik van Riel <riel@...riel.com>,
 Harry Yoo <harry.yoo@...cle.com>, Zi Yan <ziy@...dia.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Nico Pache <npache@...hat.com>,
 Ryan Roberts <ryan.roberts@....com>, Dev Jain <dev.jain@....com>,
 Jakub Matena <matenajakub@...il.com>, Wei Yang <richard.weiyang@...il.com>,
 Barry Song <baohua@...nel.org>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via
 MREMAP_RELOCATE_ANON

>>>>
>>>> Or: separate but maybe awful idea, but if the problem is the number of VMAs
>>>> maybe we could try harder based on the map count? i.e if
>>>> map_count > (max_map_count / 2), try to relocate anon.
>>>
>>> Interesting, though that'd make some things randomly merge and other stuff not,
>>> and you really have to consistently do this stuff to make things mergeable.
>>
>> Yes, I'd prefer if we can make it more predictable.
>>
>> (Of course, the VMA region size could also be used as an input to a policy.
>> e.g., small move -> much fragmentation -> merge, large move -> less
>> fragmentation -> don't care. Knowing about the use cases that use mremap()
>> of anon memory and how they might be affected could be very valuable. Maybe
>> it's mostly moving a handful of pages where we most care about this
>> optimization?).
> 
> I think fundamentally there are two problems:
> 
> 1. Unexpected VMA fragmentation leading to later mremap() failure.
> 2. Unnecessary VMA proliferation.
> 
> So we could fix 1 with a 'allow multiple VMAs to be moved if no resize'
> patch.

Yes. Which might end up easier (well, okay, different level of 
complexity, at least not messing with folio->)

And of course the relocate anon stuff is about 2.
> 
> In theory we could combine it, but things could become complicated as then
> it's mulitple VMA/anon_vma merges.

Yes.

-- 
Cheers,

David / dhildenb