From: Sean Christopherson <seanjc@google.com>
To: Rongqing Li <lirongqing@baidu.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH] KVM: x86/mmu: Don't create kvm-nx-lpage-re kthread if not itlb_multihit
Date: Thu, 30 Mar 2023 12:19:43 -0700 [thread overview]
Message-ID: <ZCXgsCYk1AWYvTsP@google.com> (raw)
In-Reply-To: <b1d9bf5a35d545879cb4eca4037b5280@baidu.com>
On Thu, Mar 30, 2023, Li,Rongqing wrote:
> > From: Sean Christopherson <seanjc@google.com>
> > On Thu, Mar 23, 2023, lirongqing@baidu.com wrote:
> > > From: Li RongQing <lirongqing@baidu.com>
> > >
> > > if CPU has not X86_BUG_ITLB_MULTIHIT bug, kvm-nx-lpage-re kthread is
> > > not needed to create
> >
> > Unless userspace forces the mitigation to be enabled, which can be done while
> > KVM is running. I agree that spinning up a kthread that is unlikely to be used is
> > less than ideal, but the ~8KiB or so overhead is per-VM and not really all that
> > notable, e.g. KVM's page tables easily exceed that.
> >
>
> A thread will create lots of proc file, and slow the command, like: ps
"ps" doesn't seem like a performance critical operation though. Again, I'm not
completely against letting the admin opt-out entirely, but I do want sufficient
justification for the extra complexity, both in the code base and in documentation.
next prev parent reply other threads:[~2023-03-30 19:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 7:18 [PATCH] KVM: x86/mmu: Don't create kvm-nx-lpage-re kthread if not itlb_multihit lirongqing
2023-03-23 14:20 ` Sean Christopherson
2023-03-23 22:32 ` Huang, Kai
2023-03-23 22:40 ` Sean Christopherson
2023-03-23 23:16 ` Huang, Kai
2023-03-30 8:18 ` Li,Rongqing
2023-03-30 19:19 ` Sean Christopherson [this message]
2023-05-02 2:07 ` Robert Hoo
2023-05-05 12:42 ` zhuangel570
2023-05-05 17:44 ` Sean Christopherson
2023-05-06 7:12 ` zhuangel570
2023-05-06 14:59 ` Robert Hoo
2023-05-06 15:30 ` zhuangel570
2023-05-06 14:49 ` Robert Hoo
2023-05-07 1:18 ` Robert Hoo
2023-05-05 17:56 ` Jim Mattson
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=ZCXgsCYk1AWYvTsP@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--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.