[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd942b04-f655-43bc-a238-68266d21ecf9@redhat.com>
Date: Tue, 17 Jun 2025 12:01:22 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Harry Yoo <harry.yoo@...cle.com>
Cc: 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>, Pedro Falcato <pfalcato@...e.de>,
Rik van Riel <riel@...riel.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 01/11] mm/mremap: introduce more mergeable mremap via
MREMAP_RELOCATE_ANON
>>> I really wish we can find a way to not require the fallback.
>>
>> Maybe split the VMA at the point where it fails, instead of undo?
>
> I don't think this is actually possible without major rework as we've separated
> the VMA and folio, page table parts of the operation.
>
> Let me put thoughts on this in reply to David so we don't split conversation
> (pun intended ;) I think we have other options also.
:)
I'm still trying to wrap my head around alternatives, and possible
simplifications ... oh my is this all complicated.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists