Re: [RFC] KVM: arm/arm64: optimize vSGI injection performance

[Marc Zyngier <maz@kernel.org>]

On Tue, 22 Aug 2023 04:51:30 +0100,
zhaoxu <zhaoxu.35@bytedance.com> wrote:
> 
> hi marc, thanks for reviewing.
> 
> On 2023/8/21 18:16, Marc Zyngier wrote:
> >>> This work is based on v5.4, and here is test data:
> > 
> > This is a 4 year old kernel. I'm afraid you'll have to provide
> > something that is relevant to a current (e.i. v6.5) kernel.
> > 
> In fact, the core vCPU search algorithm remains the same in the latest
> kernel: iterate all vCPUs, if mpidr matches, inject. next version will
> based on latest kernel.

My point is that performance numbers on such an ancient kernel hardly
make any sense, as a large portion of the code will be different. We
aim to live in the future, not in the past.

>
> >>> Based on the test results, the performance of vm  with less than 16 cores remains almost the same,
> >>> while significant improvement can be observed with more than 16
> >>> cores.
> > 
> > This triggers multiple questions:
> > 
> > - what is the test being used? on what hardware? how can I reproduce
> >    this data?
> > 
> 1. I utilized the ipi_benchmark
> (https://patchwork.kernel.org/project/linux-arm-kernel/patch/20171211141600.24401-1-ynorov@caviumnetworks.com/)
> with a modification to the Normal IPI target in the following manner:
> smp_call_function_single(31, handle_ipi, &time, 1).
> 2. On kunpeng 920 platform.
> 3. Using ipi_benchmark but change the target cpu in Normal IPI case,
> and use bcc or bpftrace to measuret the execution time of
> vgic_v3_dispatch_sgi.

So this is not a self contained benchmark, that on top of it requires
some vague additional changes. Great.

> > - which current guest OS *currently* make use of broadcast or 1:N
> >    SGIs? Linux doesn't and overall SGI multicasting is pretty useless
> >    to an OS.
> > 
> > [...]
> Yes, arm64 linux almost never send broadcast ipi. I will use another
> test data to prove performence improvement

Exactly. I also contend that *no* operating system uses broadcast (or
even multicast) signalling, because this is a very pointless
operation.

So what are you optimising for?

> > 
> >>>   /*
> >>> - * Compare a given affinity (level 1-3 and a level 0 mask, from the SGI
> >>> - * generation register ICC_SGI1R_EL1) with a given VCPU.
> >>> - * If the VCPU's MPIDR matches, return the level0 affinity, otherwise
> >>> - * return -1.
> >>> + * Get affinity routing index from ICC_SGI_* register
> >>> + * format:
> >>> + *     aff3       aff2       aff1            aff0
> >>> + * |- 8 bits -|- 8 bits -|- 8 bits -|- 4 bits or 8bits -|
> > 
> > OK, so you are implementing RSS support:
> > 
> > - Why isn't that mentioned anywhere in the commit log?
> > 
> > - Given that KVM actively limits the MPIDR to 4 bits at Aff0, how does
> >    it even work the first place?
> > 
> > - How is that advertised to the guest?
> > 
> > - How can the guest enable RSS support?
> > 
> thanks to mention that, I also checked the relevant code, guest can't
> enable RSS, it was my oversight. This part has removed in next
> version.

Then what's the point of your patch? You don't explain anything, which
makes it very hard to guess what you're aiming for.

      M.

-- 
Without deviation from the norm, progress is not possible.