From: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
Zi Yan <ziy@nvidia.com>,
Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <ljs@kernel.org>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>, Rik van Riel <riel@surriel.com>,
Vlastimil Babka <vbabka@kernel.org>, Harry Yoo <harry@kernel.org>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Joanne Koong <joannelkoong@gmail.com>
Subject: Re: [RFC PATCH 0/2] mm/huge_memory: find partially mapped shared folios with NO_PAGE_MAPCOUNT
Date: Sat, 14 Nov 2026 13:46:05 +0100 [thread overview]
Message-ID: <5ff13e10-d8a6-43ed-a718-8b34ee08d4e4@gmail.com> (raw)
In-Reply-To: <3744f956-8179-45f3-9d87-c99c82b2f8db@kernel.org>
On 11/13/26 9:16 PM, David Hildenbrand (Arm) wrote:
>>> (b) What is the overhead from having way too many folios in the deferred split list.
>>>
>>
>> I don't know yet. I only measured the walk in a TCG guest, nothing on
>> how long the list gets
>
> That would be really interesting. I assume there are some cases where a simple
> fork+exec would already add pages to the deferred split list even thought they
> are briefly after fully mapped by the parent.
>
I tested and, yes, it does. bash doing 200 fork+exec with 64K always
queued 2 folios in total.
[snip]
>>> Maybe one could track it a bit broader? "any page in this set of 16 pages is
>>> present". Reclaiming a single 4k page from a 2M folios is barely worth it.
>>>
>>
>> yes, that works. maybe with the group size scaled to the folio, so the
>> map is one long on the stack and 64K folio still gets one bit per page?
>>
>
> As an alternative, could we also just look for the next page incrementally?
>
> Like, start with offset 0. When we see that, move to offset 1, when we see that,
> move to offset 2 ... and once we saw all pages that way, stop the walk.
>
> I'd assume that, as long as VMAs don't get remapped, that should likely work in
> most cases, right?
>
I tried it. if the parent keeps the second half and the child the first,
a fully mapped folio looks partially mapped. maybe the one long map is
better here?
>> however, maybe if I don't have real evidence, better drop it?
>
> I'd be very interested in an efficient way to test if a folio is partially
> mapped, and where the holes are.
>
> Knowing about the holes could guide a targeted buddy-like folio split.
>
> There was also the idea of letting folio_referenced() for that purpose, when we
> area already doing an rmap walk.
>
okay, I could try that. would you rather have it without the shrinker
walk? with no swap, reclaim wouldn't check those folios.
--
cheers,
jose a. p-a
prev parent reply other threads:[~2026-11-14 12:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 11:31 [RFC PATCH 0/2] mm/huge_memory: find partially mapped shared folios with NO_PAGE_MAPCOUNT Jose A. Perez de Azpillaga
2026-11-11 11:31 ` [RFC PATCH 1/2] mm/huge_memory: check split_underused_thp in the caller of deferred_split_folio() Jose A. Perez de Azpillaga
2026-11-11 11:31 ` [RFC PATCH 2/2] mm/huge_memory: detect partially mapped shared folios without per-page mapcounts Jose A. Perez de Azpillaga
2026-11-12 11:36 ` sashiko-bot
2026-11-12 12:43 ` Jose A. Perez de Azpillaga
2026-11-12 12:46 ` [RFC PATCH 0/2] mm/huge_memory: find partially mapped shared folios with NO_PAGE_MAPCOUNT David Hildenbrand (Arm)
2026-11-12 13:03 ` Jose A. Perez de Azpillaga
2026-11-13 20:16 ` David Hildenbrand (Arm)
2026-11-14 12:46 ` Jose A. Perez de Azpillaga [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ff13e10-d8a6-43ed-a718-8b34ee08d4e4@gmail.com \
--to=azpijr@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=joannelkoong@gmail.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.