On Tue, 22 Aug 2023 04:51:30 +0100, zhaoxu <zhaoxu.35@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx/) > 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.
