From: Marc Zyngier <maz@kernel.org>
To: Zhiqiang Ni <nizhiqiang1@huawei.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
<wanghaibin.wang@huawei.com>, <tangnianyao@huawei.com>,
<wangzhou1@hisilicon.com>, <yuzenghui@huawei.com>,
<wangyanan55@huawei.com>, <jiangkunkun@huawei.com>,
<jiaqingtong@huawei.com>
Subject: Re: [bug report] KVM: arm64: vgic-its: Performance degradation on GICv3 LPI injection
Date: Thu, 24 Oct 2024 09:00:56 +0100 [thread overview]
Message-ID: <86y12e2amf.wl-maz@kernel.org> (raw)
In-Reply-To: <bb4aeb68-c77b-4071-bca5-d129a1c5f6f3@huawei.com>
On Thu, 24 Oct 2024 06:06:58 +0100,
Zhiqiang Ni <nizhiqiang1@huawei.com> wrote:
>
> Hi all,
>
> I found a performance degradation on GICv3 LPI injection after this
> commit ad362fe07fecf0aba839ff2cc59a3617bd42c33f(KVM: arm64: vgic-its:
> Avoid potential UAF in LPI translation cache).
>
> In my testcase, the vm's configuration is 60 VCPU 120G RAM with a
> 32-queue NIC and the kernel version is 5.10. The number of new TCP
> connections per second changed from 150,000 to 50,000 after this
> patch, with the %sys of cpu changed from 15% to 85%.
What is the VM running? How is the traffic generated? Without a
reproducer, I struggle to see how we are going to analyse this issue.
We can't go back to the previous situation anyway, as it has been
shown that what we had before was simply unsafe (the commit message
explains why).
> From the ftrace, I found that the duration of vgic_put_irq() is
> 13.320 us, which may be the reason for the performance degradation.
>
> The call stack looks like below:
> kvm_arch_set_irq_inatomic()
> vgic_has_its();
> vgic_its_inject_cached_translation()
> vgic_its_check_cache()
> vgic_queue_irq_unlock()
> vgic_put_irq()
Are you suggesting that it is the combination of vgic_get_irq_kref() +
vgic_irq_put() that leads to excessive latency? Both are essentially
atomic operations, which should be pretty cheap on a modern CPU
(anything with FEAT_LSE).
The patch below indicates that you are looking at a rather old kernel
(6.8). What is the result on a more recent kernel (from 6.10)?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-10-24 8:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 5:06 [bug report] KVM: arm64: vgic-its: Performance degradation on GICv3 LPI injection Zhiqiang Ni
2024-10-24 6:08 ` Zhiqiang Ni
2024-10-24 8:00 ` Marc Zyngier [this message]
2024-10-24 20:14 ` Oliver Upton
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=86y12e2amf.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=jiangkunkun@huawei.com \
--cc=jiaqingtong@huawei.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nizhiqiang1@huawei.com \
--cc=oliver.upton@linux.dev \
--cc=tangnianyao@huawei.com \
--cc=wanghaibin.wang@huawei.com \
--cc=wangyanan55@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=yuzenghui@huawei.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;
as well as URLs for NNTP newsgroup(s).