linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zeng Guang <guang.zeng@intel.com>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm <kvm@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Hu, Robert" <robert.hu@intel.com>,
	"Gao, Chao" <chao.gao@intel.com>
Subject: Re: [PATCH v2 0/6] IPI virtualization support for VM
Date: Fri, 23 Jul 2021 15:16:31 +0800	[thread overview]
Message-ID: <4e8f8b7f-0b20-5c2a-f23d-3f5d5321dd3a@intel.com> (raw)
In-Reply-To: <CANRm+CywPSiW=dniYEnUhYnK0NGGnnxV53AdC0goivndn6KR5g@mail.gmail.com>

On 7/23/2021 2:11 PM, Wanpeng Li wrote:
> On Fri, 23 Jul 2021 at 13:41, Zeng Guang <guang.zeng@intel.com> wrote:
>
> --------------------------------------
> IPI microbenchmark:
> (https://lore.kernel.org/kvm/20171219085010.4081-1-ynorov@caviumnetworks.com)
>
> 2 vCPUs, 1:1 pin vCPU to pCPU, guest VM runs with idle=poll, x2APIC mode
> Improve the performance for unicast ipi is as expected, however, I
> wonder whether the broadcast performance is worse than PV
> IPIs/Thomas's IPI shorthands(IPI shorthands are supported by upstream
> linux apic/x2apic driver). The hardware acceleration is not always
> outstanding on AMD(https://lore.kernel.org/kvm/CANRm+Cx597FNRUCyVz1D=B6Vs2GX3Sw57X7Muk+yMpi_hb+v1w@mail.gmail.com/),
> how about your Intel guys? Please try a big VM at least 96 vCPUs as
> below or more bigger.

Intel IPIv target to accelerate unicast ipi process, not benefit to 
broadcast performance.

As to IPI benchmark, it's not big different to test with large or small 
scale of vCPUs. In essential, Normal IPI test try
to send ipi to any other online CPU in sequence. The cost on IPI process 
itself should be similar.

>> Result with IPIv enabled:
>>
>> Dry-run:                         0,             272798 ns
>> Self-IPI:                  5094123,           11114037 ns
>> Normal IPI:              131697087,          173321200 ns
>> Broadcast IPI:                   0,          155649075 ns
>> Broadcast lock:                  0,          161518031 ns
>>
>> Result with IPIv disabled:
>>
>> Dry-run:                         0,             272766 ns
>> Self-IPI:                  5091788,           11123699 ns
>> Normal IPI:              145215772,          174558920 ns
>> Broadcast IPI:                   0,          175785384 ns
>> Broadcast lock:                  0,          149076195 ns
>>
>>
>> As IPIv can benefit unicast IPI to other CPU, Noraml IPI test case gain
>> about 9.73% time saving on average out of 15 test runs when IPIv is
>> enabled.
>>
>>                  w/o IPIv                w/ IPIv
>> Normal IPI:     145944306.6 ns          131742993.1 ns
>> %Reduction                              -9.73%
>>
>> --------------------------------------
>> hackbench:
>>
>> 8 vCPUs, guest VM free run, x2APIC mode
>> ./hackbench -p -l 100000
>>
>>                  w/o IPIv        w/ IPIv
>> Time:           91.887          74.605
>> %Reduction:                     -18.808%
>>
>> 96 vCPUs, guest VM free run, x2APIC mode
>> ./hackbench -p -l 1000000
>>
>>                  w/o IPIv        w/ IPIv
>> Time:           287.504         235.185
>> %Reduction:                     -18.198%
> Good to know this.
>
>      Wanpeng

      reply	other threads:[~2021-07-23  7:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23  5:16 [PATCH v2 0/6] IPI virtualization support for VM Zeng Guang
2021-07-23  5:16 ` [PATCH v2 1/6] x86/feat_ctl: Add new VMX feature, Tertiary VM-Execution control Zeng Guang
2021-07-23  5:16 ` [PATCH v2 2/6] KVM: VMX: Extend BUILD_CONTROLS_SHADOW macro to support 64-bit variation Zeng Guang
2021-07-23  5:16 ` [PATCH v2 3/6] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config Zeng Guang
2021-07-23  5:16 ` [PATCH v2 4/6] KVM: VMX: dump_vmcs() reports tertiary_exec_control field as well Zeng Guang
2021-07-23  5:16 ` [PATCH v2 5/6] KVM: x86: Support interrupt dispatch in x2APIC mode with APIC-write VM exit Zeng Guang
2021-07-23  5:16 ` [PATCH v2 6/6] KVM: VMX: enable IPI virtualization Zeng Guang
2021-07-23  6:11 ` [PATCH v2 0/6] IPI virtualization support for VM Wanpeng Li
2021-07-23  7:16   ` Zeng Guang [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=4e8f8b7f-0b20-5c2a-f23d-3f5d5321dd3a@intel.com \
    --to=guang.zeng@intel.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jethro@fortanix.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kai.huang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kernellwp@gmail.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --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).