[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k048f3cm.wl-maz@kernel.org>
Date: Sun, 06 Nov 2022 16:35:21 +0000
From: Marc Zyngier <maz@...nel.org>
To: Usama Arif <usama.arif@...edance.com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
kvmarm@...ts.cs.columbia.edu, kvm@...r.kernel.org,
linux-doc@...r.kernel.org,
virtualization@...ts.linux-foundation.org, linux@...linux.org.uk,
yezengruan@...wei.com, catalin.marinas@....com, will@...nel.org,
steven.price@....com, mark.rutland@....com, bagasdotme@...il.com,
fam.zheng@...edance.com, liangma@...ngbit.com,
punit.agrawal@...edance.com
Subject: Re: [v2 0/6] KVM: arm64: implement vcpu_is_preempted check
On Fri, 04 Nov 2022 06:20:59 +0000,
Usama Arif <usama.arif@...edance.com> wrote:
>
> This patchset adds support for vcpu_is_preempted in arm64, which
> allows the guest to check if a vcpu was scheduled out, which is
> useful to know incase it was holding a lock. vcpu_is_preempted can
> be used to improve performance in locking (see owner_on_cpu usage in
> mutex_spin_on_owner, mutex_can_spin_on_owner, rtmutex_spin_on_owner
> and osq_lock) and scheduling (see available_idle_cpu which is used
> in several places in kernel/sched/fair.c for e.g. in wake_affine to
> determine which CPU can run soonest):
[...]
> pvcy shows a smaller overall improvement (50%) compared to
> vcpu_is_preempted (277%). Host side flamegraph analysis shows that
> ~60% of the host time when using pvcy is spent in kvm_handle_wfx,
> compared with ~1.5% when using vcpu_is_preempted, hence
> vcpu_is_preempted shows a larger improvement.
And have you worked out *why* we spend so much time handling WFE?
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists