mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Fred Griffoul <griffoul@gmail.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: Mushahid Hussain <hmushi@amazon.co.uk>,
	nh-open-source@amazon.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/2] KVM: Allocate small memslot metadata with kvzalloc()
Date: Thu,  5 Nov 2026 00:01:25 +0000	[thread overview]
Message-ID: <20261105000127.63664-1-griffoul@gmail.com> (raw)

From: Fred Griffoul <fgriffo@amazon.co.uk>

__vcalloc() makes every memslot metadata allocation at least one page,
so small memslots waste most of their lpage_info and dirty bitmap, and
memslots below 512 GiB waste most of a page on their 1 GiB lpage_info.
Mushahid's patch [1] switched those arrays to kvcalloc(), and Sean
suggested dedicated helpers for memslot metadata with a pivot that makes
sense for KVM instead [2].

Patch 1 adds the helpers and routes the dirty bitmap, rmaps, lpage_info
and write-tracking arrays through them, with no functional change.
Patch 2 makes the helpers use kvzalloc() up to KMALLOC_MAX_CACHE_SIZE,
where kmalloc() never uses more memory than vmalloc(), and keeps
__vcalloc() above.

I ran the memslot and dirty logging selftests with the TDP MMU and with
kvm.tdp_mmu=0, plus a check that one-page memslots no longer take a
vmalloc area each and that a 1 TiB memslot still gets its rmaps from
vmalloc.

Fred

Changes in v2:
  - Split the helpers and the allocator change into two patches
  - Pivot on KMALLOC_MAX_CACHE_SIZE instead of INT_MAX

v1: https://lore.kernel.org/kvm/20261103234734.45413-1-griffoul@gmail.com/

[1] https://lore.kernel.org/all/20260815142218.85067-1-hmushi@amazon.co.uk/
[2] https://lore.kernel.org/all/arr1VgGZmgUmY4hc@google.com/

Fred Griffoul (2):
  KVM: Add helpers to allocate memslot metadata
  KVM: Use kvzalloc() for memslot metadata that fits in a slab bucket

 arch/x86/kvm/mmu/page_track.c |  6 +++---
 arch/x86/kvm/x86.c            | 10 +++++-----
 include/linux/kvm_host.h      |  2 ++
 virt/kvm/kvm_main.c           | 22 ++++++++++++++++++++--
 4 files changed, 30 insertions(+), 10 deletions(-)


base-commit: d21eef2084a9af87ac2a783bc7c2b175ba114e4e
-- 
2.47.3


             reply	other threads:[~2026-11-05  0:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  0:01 Fred Griffoul [this message]
2026-11-05  0:01 ` [PATCH v2 1/2] KVM: Add helpers to allocate memslot metadata Fred Griffoul
2026-11-05  0:01 ` [PATCH v2 2/2] KVM: Use kvzalloc() for memslot metadata that fits in a slab bucket Fred Griffoul

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=20261105000127.63664-1-griffoul@gmail.com \
    --to=griffoul@gmail.com \
    --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 \
    --cc=seanjc@google.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

all inboxes | Powered by JetHome®