[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5cb68a7-19eb-40aa-95f7-51fd004a3f8e@redhat.com>
Date: Fri, 29 Aug 2025 10:42:45 +0200
From: David Hildenbrand <david@...hat.com>
To: Lokesh Gidra <lokeshgidra@...gle.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Harry Yoo <harry.yoo@...cle.com>, Zi Yan <ziy@...dia.com>,
Barry Song <21cnbao@...il.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
Peter Xu <peterx@...hat.com>, Suren Baghdasaryan <surenb@...gle.com>,
Kalesh Singh <kaleshsingh@...gle.com>, android-mm <android-mm@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>, Jann Horn <jannh@...gle.com>,
Rik van Riel <riel@...riel.com>, Vlastimil Babka <vbabka@...e.cz>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>
Subject: Re: [DISCUSSION] Unconditionally lock folios when calling rmap_walk()
>>
>> I do wonder if we can identify this case and handle things differently.
>>
>> Perhaps even saying 'try and get the rmap lock, but if there's "too much"
>> contention, grab the folio lock.
>
> Can you please elaborate what you mean? Where do you mean we can
> possibly do something like this?
>
> UFFD move only works on PageAnonExclusive folios. So, would it help
> (in terms of avoiding contention) if we were to change the condition:
I think we shouldn't be using PAE here. Once could consider using
folio_maybe_mapped_shared(), and assume contention on the folio lock if
it is maybe mapped shared.
But the real question is with whom we would be contending for the folio
lock.
Is it really other processes mapping that folio? I'm not so sure.
--
Cheers
David / dhildenb
Powered by blists - more mailing lists