From: Eduardo Habkost <ehabkost@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: linux-kernel@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] kvm: rename HINTS_DEDICATED to KVM_HINTS_REALTIME
Date: Fri, 18 May 2018 13:04:31 -0300 [thread overview]
Message-ID: <20180518160431.GX25013@localhost.localdomain> (raw)
In-Reply-To: <20180517225316-mutt-send-email-mst@kernel.org>
CCing qemu-devel, as I'm now discussing userspace.
On Thu, May 17, 2018 at 10:55:33PM +0300, Michael S. Tsirkin wrote:
> On Thu, May 17, 2018 at 03:46:58PM -0300, Eduardo Habkost wrote:
> > On Thu, May 17, 2018 at 05:54:24PM +0300, Michael S. Tsirkin wrote:
> > > HINTS_DEDICATED seems to be somewhat confusing:
> > >
> > > Guest doesn't really care whether it's the only task running on a host
> > > CPU as long as it's not preempted.
> > >
> > > And there are more reasons for Guest to be preempted than host CPU
> > > sharing, for example, with memory overcommit it can get preempted on a
> > > memory access, post copy migration can cause preemption, etc.
> > >
> > > Let's call it KVM_HINTS_REALTIME which seems to better
> > > match what guests expect.
> > >
> > > Also, the flag most be set on all vCPUs - current guests assume th.
> > > Note so in the documentation.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > > Documentation/virtual/kvm/cpuid.txt | 6 +++---
> > > arch/x86/include/uapi/asm/kvm_para.h | 2 +-
> > > arch/x86/kernel/kvm.c | 8 ++++----
> > > 3 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
> > > index d4f33eb8..ab022dc 100644
> > > --- a/Documentation/virtual/kvm/cpuid.txt
> > > +++ b/Documentation/virtual/kvm/cpuid.txt
> > > @@ -72,8 +72,8 @@ KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
> > >
> > > flag || value || meaning
> > > ==================================================================================
> > > -KVM_HINTS_DEDICATED || 0 || guest checks this feature bit to
> > > - || || determine if there is vCPU pinning
> > > - || || and there is no vCPU over-commitment,
> > > +KVM_HINTS_REALTIME || 0 || guest checks this feature bit to
> > > + || || determine that vCPUs are never
> > > + || || preempted for an unlimited time,
> > > || || allowing optimizations
> >
> > My understanding of the original patch is that the intention is
> > to tell the guest that it is very unlikely to be preempted,
> > so it
> > can choose a more appropriate spinlock implementation. This
> > description implies that the guest will never be preempted, which
> > is much stronger guarantee.
>
> Note:
>
> ... for an unlimited time.
Which still sounds like a stronger guarantee than the original
description. But:
>
> >
> > Isn't this new description incompatible with existing usage of
> > the hint, which might include people who just use vCPU pinning
> > but no mlock?
>
> Without mlock you should always use pv spinlocks.
>
> Otherwise you risk blocking on a lock taken by
> a VCPU that is in turn blocked on IO, where the IO
> is not completing because CPU is being used up
> spinning.
So the stronger guarantee seems necessary.
Now what should host userspace do if the user is trying to run an
existing configuration where the CPUID hint was set but memory is
not pinned?
--
Eduardo
next parent reply other threads:[~2018-05-18 16:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1526568841-35372-1-git-send-email-mst@redhat.com>
[not found] ` <20180517184658.GA1543@localhost.localdomain>
[not found] ` <20180517225316-mutt-send-email-mst@kernel.org>
2018-05-18 16:04 ` Eduardo Habkost [this message]
2018-05-18 17:01 ` [Qemu-devel] [PATCH] kvm: rename HINTS_DEDICATED to KVM_HINTS_REALTIME Michael S. Tsirkin
2018-05-18 17:13 ` Eduardo Habkost
2018-05-18 17:18 ` Paolo Bonzini
2018-05-18 17:54 ` Eduardo Habkost
2018-05-18 17:17 ` Paolo Bonzini
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=20180518160431.GX25013@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=corbet@lwn.net \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).