From: David Hildenbrand <david@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Jason Gunthorpe <jgg@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lizhe.67@bytedance.com" <lizhe.67@bytedance.com>
Subject: Re: [GIT PULL] VFIO updates for v6.17-rc1
Date: Tue, 5 Aug 2025 15:47:47 +0200 [thread overview]
Message-ID: <4c68eb5d-1e0e-47f3-a1fc-1e063dd1fd47@redhat.com> (raw)
In-Reply-To: <CAHk-=wg75QKYCCCAtbro5F7rnrwq4xYuKmKeg4hUwuedcPXuGw@mail.gmail.com>
On 05.08.25 15:36, Linus Torvalds wrote:
> On Tue, 5 Aug 2025 at 16:26, Jason Gunthorpe <jgg@nvidia.com> wrote:
>>
>> David, there is another alternative to prevent this, simple though a
>> bit wasteful, just allocate a bit bigger to ensure the allocation
>> doesn't end on an exact PAGE_SIZE boundary?
>
> So I don't mind adding a check for "page_section()", because at least
> that makes sense.
>
> But yes, it would also probably be a good idea to try to minimize
> SPARSEMEM without VMEMMAP. I'd love to get rid of it entirely, of
> course, but even if that isn't possible, I'd *really* just like people
> to try to make sure that it's neve ra valid thing to try to combine
> memory across different sections.
>
> David mentioned the 1GB hugepage folios, and I really thought that
> even *those* were all in one section. They *should* be.
The memory section size on x86 is always 128 MiB. Even with SPARSEMEM.
There are weird interactions between memory section size and memory
hotplug / DAX, so we try to keep it small'ish.
It's more that we don't care that much about memory section size with
SPARSEMEM because nth_page() and everything around that is just plain
simple.
>
> Do we have any relevant architectures that still do SPARSEMEM without
> VMEMMAP? Because if it's purely some "legacy architecture" thing (ie
> x86-32), how about just saying "no 1GB hugepages for you".
arch/arm64/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/loongarch/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/powerpc/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/riscv/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
arch/s390/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/sparc/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/x86/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE if X86_64
But SPARSEMEM_VMEMMAP is still user-selectable.
I would assume SPARSEMEM_VMEMMAP_ENABLE support would cover most hugetlb
+ dax users indeed, at least when it comes to gigantic folios.
Would have to figure out why someone would want to disable it (limited
vspace? but that should also not really be a problem on 64bit I think).
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-08-05 13:47 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 22:22 [GIT PULL] VFIO updates for v6.17-rc1 Alex Williamson
2025-08-04 23:55 ` Linus Torvalds
2025-08-05 0:53 ` Alex Williamson
2025-08-05 7:47 ` David Hildenbrand
2025-08-05 11:49 ` Jason Gunthorpe
2025-08-05 12:07 ` David Hildenbrand
2025-08-05 12:38 ` Jason Gunthorpe
2025-08-05 12:41 ` David Hildenbrand
2025-08-05 12:56 ` Jason Gunthorpe
2025-08-05 13:05 ` David Hildenbrand
2025-08-05 13:15 ` Linus Torvalds
2025-08-05 13:19 ` David Hildenbrand
2025-08-05 13:22 ` David Hildenbrand
2025-08-05 13:00 ` Linus Torvalds
2025-08-05 13:20 ` David Hildenbrand
2025-08-05 13:24 ` David Hildenbrand
2025-08-05 13:28 ` Linus Torvalds
2025-08-05 13:37 ` David Hildenbrand
2025-08-05 13:49 ` Linus Torvalds
2025-08-05 13:25 ` Jason Gunthorpe
2025-08-05 13:33 ` David Hildenbrand
2025-08-05 13:55 ` Jason Gunthorpe
2025-08-05 14:10 ` David Hildenbrand
2025-08-05 14:20 ` Jason Gunthorpe
2025-08-05 14:22 ` David Hildenbrand
2025-08-05 14:24 ` Jason Gunthorpe
2025-08-05 14:26 ` David Hildenbrand
2025-08-05 13:36 ` Linus Torvalds
2025-08-05 13:47 ` David Hildenbrand [this message]
2025-08-05 13:51 ` Linus Torvalds
2025-08-05 13:55 ` David Hildenbrand
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=4c68eb5d-1e0e-47f3-a1fc-1e063dd1fd47@redhat.com \
--to=david@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=jgg@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizhe.67@bytedance.com \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).