From: Matthew Wilcox <willy@infradead.org>
To: Artem Lytkin <iprintercanon@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, urezki@gmail.com,
shivamkalra98@zohomail.in, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmalloc: make vm_struct.nr_pages an unsigned long
Date: Wed, 29 Jul 2026 19:28:36 +0100 [thread overview]
Message-ID: <ampGVI1MLmnLksnN@casper.infradead.org> (raw)
In-Reply-To: <20260729175708.7074-1-iprintercanon@gmail.com>
On Wed, Jul 29, 2026 at 08:57:08PM +0300, Artem Lytkin wrote:
> A vmalloc area can hold more than 2^32 pages, but the page counts
I had a "wait, what, really?" moment. And it can! 2^32 pages is 16TiB,
and x86-64 says:
ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base)
So we can have _one_ allocation that is more than 2^32 pages. But I'm
not sure where we'll get the memory to populate it from.
https://blogs.oracle.com/cloud-infrastructure/announcing-oci-compute-e6-acceleron-instances
says I can get 2.3TB of memory in a single machine, which is a factor of
8 away from where we'd need to be to actually hit this.
Intel are adveertising a max memory of 1.5TiB on the 6990E+ (128GiB *
12 channels). So if you put 8 Xeons in a box and loaded it up, that
could get you to 12TiB.
I'm not saying we shouldn't fix this, but it's all theoretical for now,
right?
next prev parent reply other threads:[~2026-07-29 18:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 17:57 [PATCH] mm/vmalloc: make vm_struct.nr_pages an unsigned long Artem Lytkin
2026-07-29 18:28 ` Matthew Wilcox [this message]
2026-07-29 21:45 ` Andrew Morton
2026-07-30 9:07 ` Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 0/3] mm/vmalloc: stop truncating byte counts derived from nr_pages Artem Lytkin
2026-07-30 17:11 ` [PATCH v3] mm/vmalloc: make vm_struct.nr_pages an unsigned long Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 1/3] mm/vmalloc: fix 32-bit truncation of the area size in vread_iter() Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 2/3] mm/vmalloc: fix 32-bit truncation in the vrealloc() grow-in-place check Artem Lytkin
2026-07-30 9:06 ` [PATCH v2 3/3] mm/vmalloc: make vm_struct.nr_pages an unsigned long Artem Lytkin
2026-07-30 13:04 ` [PATCH] " Uladzislau Rezki
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=ampGVI1MLmnLksnN@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=iprintercanon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shivamkalra98@zohomail.in \
--cc=urezki@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox