From: Marc Zyngier <maz@kernel.org>
To: Nianyao Tang <tangnianyao@huawei.com>
Cc: <tglx@linutronix.de>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <guoyang2@huawei.com>,
<wangwudi@hisilicon.com>
Subject: Re: [RESPIN PATCH] irqchip/gic-v4.1: Use local 4_1 ITS to generate VSGI
Date: Mon, 01 Jul 2024 09:01:59 +0100 [thread overview]
Message-ID: <86a5j1ilqg.wl-maz@kernel.org> (raw)
In-Reply-To: <20240701062042.4128863-1-tangnianyao@huawei.com>
Please don't use "RESPIN" as a subject tag. This means nothing, and
confuses the tooling such as b4, which expects a version number.
If the code has changed in any way, increment the version number. This
really should have been a v2.
On Mon, 01 Jul 2024 07:20:42 +0100,
Nianyao Tang <tangnianyao@huawei.com> wrote:
>
> On multi-node GICv4.1 system, VSGI senders always use one certain 4_1 ITS,
> because find_4_1_its return the first its_node in list, regardless of
> which node the VSGI sender is on. This brings guest vsgi performance drop
> when VM is not deployed on the same node as this returned ITS.
s/deployed/running/
>
> On a 2-socket environment, each with one ITS and 32 cpu, GICv4.1 enabled,
> 4U8G guest, 4 vcpu is deployed on same socket.
s/deployed/running/
> When VM on socket0, kvm-unit-tests ipi_hw result is 850ns.
> When VM on socket1, it is 750ns. The reason is VSGI sender always
> use lasted reported ITS(that on socket1) to inject VSGI. The access
s/lasted/the last/
> from cpu to other-socket ITS will cost 100ns more compared to cpu to
> local ITS.
>
> To use local ITS, we can get 12% reduction in IPI latency.
s/To use/By using a/
>
> The patch modify find_4_1_its to firstly return per-cpu local_4_1_its,
Drop "the patch".
s/firstly/first/
> which is init when inherit the VPE table from the ITS on secondary CPUs.
or from another CPU.
> If fail to find local 4_1 ITS, return any 4_1 ITS like before.
>
> Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
> Reviewed-by: Marc Zyngier <maz@kernel.org>
No. I never gave this tag. You can (and probably should) add a
"Suggested-by:" tag, but not a "Reviewed-by:", until I explicitly
reply to the patch with that tag.
Please resend it as a v3 with all of the above fixed.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
prev parent reply other threads:[~2024-07-01 8:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 6:20 [RESPIN PATCH] irqchip/gic-v4.1: Use local 4_1 ITS to generate VSGI Nianyao Tang
2024-07-01 8:01 ` Marc Zyngier [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=86a5j1ilqg.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=guoyang2@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tangnianyao@huawei.com \
--cc=tglx@linutronix.de \
--cc=wangwudi@hisilicon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.