From: Sean Christopherson <seanjc@google.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Colin Ian King <colin.i.king@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: VMX: make vmx_init a late init call to get to init process faster
Date: Fri, 5 Apr 2024 16:20:41 -0700 [thread overview]
Message-ID: <ZhCHSYwS5_o-OKs0@google.com> (raw)
In-Reply-To: <20240323080541.10047-2-pmenzel@molgen.mpg.de>
On Sat, Mar 23, 2024, Paul Menzel wrote:
> From: Colin Ian King <colin.i.king@intel.com>
>
> Making vmx_init a late initcall improves QEMU kernel boot times to
> get to the init process. Average of 100 boots, QEMU boot average
> reduced from 0.776 seconds to 0.622 seconds (~19.8% faster) on
> Alder Lake i9-12900 and ~0.5% faster for non-QEMU UEFI boots.
The changelog needs to better explain what "QEMU kernel boot times" means. I
assume the test is a QEMU VM running a kernel KVM_INTEL built-in? This should
also call out that late_initcall is #defined to module_init() when KVM is built
as a module.
> Signed-off-by: Colin Ian King <colin.i.king@intel.com>
> [Take patch
> https://github.com/clearlinux-pkgs/linux/commit/797db35496031b19ba37b1639ac5fa5db9159a06
> and fix spelling of Alder Lake.]
> Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
> ---
> arch/x86/kvm/vmx/vmx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index c37a89eda90f..0a9f4b20fbda 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -8783,4 +8783,4 @@ static int __init vmx_init(void)
> kvm_x86_vendor_exit();
> return r;
> }
> -module_init(vmx_init);
> +late_initcall(vmx_init);
_If_ we do this, then we should also give svm_init() and kvm_x86_init() the same
treatment. I see no reason for vmx_init() to be special.
I'm not opposed to this, but I also have zero idea if this could have a negative
impact userspace. E.g. what happens if some setup's init process expects /dev/kvm
to exist? Will this break that?
prev parent reply other threads:[~2024-04-05 23:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-23 8:05 [PATCH] KVM: VMX: make vmx_init a late init call to get to init process faster Paul Menzel
2024-03-23 8:14 ` Paul Menzel
2024-04-05 23:20 ` 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=ZhCHSYwS5_o-OKs0@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=colin.i.king@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pmenzel@molgen.mpg.de \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 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.