From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>,
Sasha Levin <sashal@kernel.org>
Cc: akpm@linux-foundation.org, corbet@lwn.net, ljs@kernel.org,
Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, skhan@linuxfoundation.org,
jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Sasha Levin <sashal@nvidia.com>,
Sanif Veeras <sveeras@nvidia.com>,
"Claude:claude-opus-4-7" <noreply@anthropic.com>
Subject: Re: [RFC 4/7] mm: add page consistency checker implementation
Date: Fri, 24 Apr 2026 20:28:14 +0200 [thread overview]
Message-ID: <12985b32-88b3-47ab-8292-2e0ec6f5fbae@kernel.org> (raw)
In-Reply-To: <aeuFnuiYDBjttEKt@plex>
On 4/24/26 17:06, Pasha Tatashin wrote:
> On 04-24 10:49, Sasha Levin wrote:
>> On Fri, Apr 24, 2026 at 04:25:41PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> One bitmap that covers all sparse memory available at boot.
>>>
>>> Conclusion: Just horrible.
>>
>> Depends on who's looking at the code :)
>>
>> I picked it for auditability: covering the whole range with two
>> memblock_alloc'd arrays means the only thing on the lookup path is the bitmap
>> words themselves, which is what the dual-bitmap invariant already checks.
>
> The issue is that we are going back in time to a flat memory,
> without NUMA or hotplug support. We need an abstraction that avoids
> allocating this memory in enormous contiguous chunks, as thit approach
> will not work on modern hardware.
>
>>
>> We could go with per-section bitmaps which will fix the waste but pull
>> mem_section[] into the trust boundary, so we'd have to start validating it too.
>
> Page-ext provides all of these capabilities, but as you described in the
> cover letter, it does not meet your requirements. Therefore, I believe
> a new abstraction layer is needed.
If we decided that we want this (and I am not convinced), we definitely want
something that supports sparsity and, in particular, something that support
memory hotplug.
--
Cheers,
David
next prev parent reply other threads:[~2026-04-24 18:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 14:00 [RFC 0/7] mm: dual-bitmap page allocator consistency checker Sasha Levin
2026-04-24 14:00 ` [RFC 1/7] mm: add generic dual-bitmap consistency primitives Sasha Levin
2026-04-24 14:00 ` [RFC 2/7] mm: add page consistency checker header Sasha Levin
2026-04-24 14:00 ` [RFC 3/7] mm: add Kconfig options for page consistency checker Sasha Levin
2026-04-24 14:00 ` [RFC 4/7] mm: add page consistency checker implementation Sasha Levin
2026-04-24 14:25 ` David Hildenbrand (Arm)
2026-04-24 14:49 ` Sasha Levin
2026-04-24 15:06 ` Pasha Tatashin
2026-04-24 18:28 ` David Hildenbrand (Arm) [this message]
2026-04-24 23:34 ` Sasha Levin
2026-04-25 5:30 ` David Hildenbrand (Arm)
2026-04-25 16:38 ` Sasha Levin
2026-04-27 12:32 ` David Hildenbrand (Arm)
2026-04-27 14:10 ` Sasha Levin
2026-04-27 15:40 ` David Hildenbrand (Arm)
2026-04-27 18:56 ` Sasha Levin
2026-04-27 19:37 ` David Hildenbrand (Arm)
2026-04-27 23:24 ` Sasha Levin
2026-04-28 7:22 ` David Hildenbrand (Arm)
2026-04-24 18:26 ` David Hildenbrand (Arm)
2026-04-24 14:00 ` [RFC 5/7] mm/page_alloc: integrate page consistency hooks Sasha Levin
2026-04-24 14:00 ` [RFC 6/7] Documentation/mm: add page consistency checker documentation Sasha Levin
2026-04-24 14:00 ` [RFC 7/7] mm/page_consistency: add KUnit tests for dual-bitmap primitives Sasha Levin
2026-04-24 15:34 ` [RFC 0/7] mm: dual-bitmap page allocator consistency checker Matthew Wilcox
2026-04-24 15:53 ` Sasha Levin
2026-04-24 15:42 ` Vlastimil Babka (SUSE)
2026-04-24 16:25 ` Sasha Levin
2026-04-25 5:51 ` David Hildenbrand (Arm)
2026-04-25 16:09 ` Sasha Levin
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=12985b32-88b3-47ab-8292-2e0ec6f5fbae@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=noreply@anthropic.com \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=sashal@kernel.org \
--cc=sashal@nvidia.com \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=sveeras@nvidia.com \
--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.