From: Sean Christopherson <seanjc@google.com>
To: Mushahid Hussain <hmushi@amazon.co.uk>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
David Hildenbrand <david@kernel.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
nh-open-source@amazon.com
Subject: Re: [PATCH] KVM: Use kvcalloc() to allocate lpage_info arrays and dirty bitmaps
Date: Mon, 28 Sep 2026 16:16:38 -0700 [thread overview]
Message-ID: <arr1VgGZmgUmY4hc@google.com> (raw)
In-Reply-To: <20260815142218.85067-1-hmushi@amazon.co.uk>
On Sat, Aug 15, 2026, Mushahid Hussain wrote:
> __vcalloc() makes every allocation at least a page, so a single page
> memslot consumes 8 KiB of vmalloc for 8 bytes of lpage_info and
> another 4 KiB for a 16 byte dirty bitmap when dirty logging is
> enabled. This overhead scales with the number of slots and VMs on a
> host, adding up to memory pressure when guest address spaces are
> fragmented into small slots.
If memslots are fragmented that badly, then the rmaps are also going to be
extremely wasteful.
> The rmap and gfn_write_track arrays keep __vcalloc() and vfree():
> the 4K rmap and gfn_write_track are per-page arrays, 8 and 2 bytes
> per 4 KiB page, which legitimately cross INT_MAX below the 8 TiB
> slot ceiling; the smaller higher-level rmaps share the 4K rmap's
> allocation loop; and none of them allocate under the TDP MMU,
Until nested virtualization gets used, and then KVM pays the overhead cost for
every memslot.
Rather than flip-flop because of a semi-arbitrary limit that has nothing to do
with KVM, I think we should provide dedicated KVM APIs for allocating memslot
metadata, and pick a pivot that makes sense for KVM. Or just pivot on INT_MAX
to route to kv() vs. v() to play nice with the "not crazy" rule.
> where the waste above was observed.
prev parent reply other threads:[~2026-09-28 23:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 14:22 [PATCH] KVM: Use kvcalloc() to allocate lpage_info arrays and dirty bitmaps Mushahid Hussain
2026-09-28 23:16 ` Sean Christopherson [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=arr1VgGZmgUmY4hc@google.com \
--to=seanjc@google.com \
--cc=david@kernel.org \
--cc=hmushi@amazon.co.uk \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pbonzini@redhat.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.