From: Sean Christopherson <seanjc@google.com>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: "Kenta Ishiguro" <kentaishiguro@sslab.ics.keio.ac.jp>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Vitaly Kuznetsov" <vkuznets@redhat.com>,
"Wanpeng Li" <wanpengli@tencent.com>,
"Jim Mattson" <jmattson@google.com>,
"Joerg Roedel" <joro@8bytes.org>,
"David Hildenbrand" <david@redhat.com>, kvm <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Pierre-Louis Aublin" <pl@sslab.ics.keio.ac.jp>,
河野健二 <kono@sslab.ics.keio.ac.jp>
Subject: Re: [RFC PATCH 0/2] Mitigating Excessive Pause-Loop Exiting in VM-Agnostic KVM
Date: Thu, 22 Apr 2021 15:58:41 +0000 [thread overview]
Message-ID: <YIGdMZIVHVp3y/J0@google.com> (raw)
In-Reply-To: <CANRm+CxMf=kwDRQE-BNbhgCARuV3fuKpDbEV2oWTeKuGhUYd+w@mail.gmail.com>
On Thu, Apr 22, 2021, Wanpeng Li wrote:
> On Thu, 22 Apr 2021 at 09:45, Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Thu, Apr 22, 2021, Kenta Ishiguro wrote:
> > > To solve problems (2) and (3), patch 2 monitors IPI communication between
> > > vCPUs and leverages the relationship between vCPUs to select boost
> > > candidates. The "[PATCH] KVM: Boost vCPU candidiate in user mode which is
> > > delivering interrupt" patch
> > > (https://lore.kernel.org/kvm/CANRm+Cy-78UnrkX8nh5WdHut2WW5NU=UL84FRJnUNjsAPK+Uww@mail.gmail.com/T/)
> > > seems to be effective for (2) while it only uses the IPI receiver
> > > information.
> >
> > On the IPI side of thing, I like the idea of explicitly tracking the IPIs,
> > especially if we can simplify the implementation, e.g. by losing the receiver
> > info and making ipi_received a bool. Maybe temporarily table Wanpeng's patch
> > while this approach is analyzed?
>
> Hi all,
>
> I evaluate my patch
Thanks for doing the testing, much appreciated!
> (https://lore.kernel.org/kvm/1618542490-14756-1-git-send-email-wanpengli@tencent.com),
> Kenta's patch 2 and Sean's suggestion. The testing environment is
> pbzip2 in 96 vCPUs VM in over-subscribe scenario (The host machine is
> 2 socket, 48 cores, 96 HTs Intel CLX box).
Are the vCPUs affined in any way? How many VMs are running? Are there other
workloads in the host? Not criticising, just asking so that others can reproduce
your setup.
> Note: the Kenta's scheduler hacking is not applied. The score of my patch is
> the most stable and the best performance.
On the other hand, Kenta's approach has the advantage of working for both Intel
and AMD. But I'm also not very familiar with AMD's AVIC, so I don't know if it's
feasible to implement a performant equivalent in svm_dy_apicv_has_pending_interrupt().
Kenda's patch is also flawed as it doesn't scale to 96 vCPUs; vCPUs 64-95 will
never get boosted.
> Wanpeng's patch
>
> The average: vanilla -> boost: 69.124 -> 61.975, 10.3%
>
> * Wall Clock: 61.695359 seconds
> * Wall Clock: 63.343579 seconds
> * Wall Clock: 61.567513 seconds
> * Wall Clock: 62.144722 seconds
> * Wall Clock: 61.091442 seconds
> * Wall Clock: 62.085912 seconds
> * Wall Clock: 61.311954 seconds
>
> Kenta' patch
>
> The average: vanilla -> boost: 69.148 -> 64.567, 6.6%
>
> * Wall Clock: 66.288113 seconds
> * Wall Clock: 61.228642 seconds
> * Wall Clock: 62.100524 seconds
> * Wall Clock: 68.355473 seconds
> * Wall Clock: 64.864608 seconds
>
> Sean's suggestion:
>
> The average: vanilla -> boost: 69.148 -> 66.505, 3.8%
>
> * Wall Clock: 60.583562 seconds
> * Wall Clock: 58.533960 seconds
> * Wall Clock: 70.103489 seconds
> * Wall Clock: 74.279028 seconds
> * Wall Clock: 69.024194 seconds
next prev parent reply other threads:[~2021-04-22 15:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 15:08 [RFC PATCH 0/2] Mitigating Excessive Pause-Loop Exiting in VM-Agnostic KVM Kenta Ishiguro
2021-04-21 15:08 ` [RFC PATCH 1/2] Prevent CFS from ignoring boost requests from KVM Kenta Ishiguro
2021-04-21 15:08 ` [RFC PATCH 2/2] Boost vCPUs based on IPI-sender and receiver information Kenta Ishiguro
2021-04-21 15:43 ` Sean Christopherson
2021-04-21 16:16 ` Sean Christopherson
2021-04-21 16:19 ` [RFC PATCH 0/2] Mitigating Excessive Pause-Loop Exiting in VM-Agnostic KVM Sean Christopherson
2021-04-22 12:21 ` Wanpeng Li
2021-04-22 15:58 ` Sean Christopherson [this message]
[not found] ` <CAOOWTGJvFB_hgSUzaqNaNigdkRXFcaK37F9V7kmL3nCG+bFz5Q@mail.gmail.com>
2021-04-26 3:02 ` Wanpeng Li
2021-04-26 3:18 ` Kenta Ishiguro
2021-04-26 3:58 ` Wanpeng Li
2021-04-26 4:10 ` Kenta Ishiguro
2021-04-22 0:55 ` Wanpeng Li
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=YIGdMZIVHVp3y/J0@google.com \
--to=seanjc@google.com \
--cc=david@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kentaishiguro@sslab.ics.keio.ac.jp \
--cc=kernellwp@gmail.com \
--cc=kono@sslab.ics.keio.ac.jp \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pl@sslab.ics.keio.ac.jp \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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