[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6e848e46f3c865f6b9d2771c8aad37a@misterjones.org>
Date: Wed, 22 Apr 2020 11:14:28 +0100
From: Marc Zyngier <maz@...terjones.org>
To: Davidlohr Bueso <dave@...olabs.net>
Cc: tglx@...utronix.de, pbonzini@...hat.com, kvm@...r.kernel.org,
Davidlohr Bueso <dbueso@...e.de>, peterz@...radead.org,
torvalds@...ux-foundation.org, bigeasy@...utronix.de,
linux-kernel@...r.kernel.org, rostedt@...dmis.org,
linux-mips@...r.kernel.org, Paul Mackerras <paulus@...abs.org>,
joel@...lfernandes.org, will@...nel.org,
kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH 4/5] kvm: Replace vcpu->swait with rcuwait
On 2020-04-22 05:07, Davidlohr Bueso wrote:
> The use of any sort of waitqueue (simple or regular) for
> wait/waking vcpus has always been an overkill and semantically
> wrong. Because this is per-vcpu (which is blocked) there is
> only ever a single waiting vcpu, thus no need for any sort of
> queue.
>
> As such, make use of the rcuwait primitive, with the following
> considerations:
>
> - rcuwait already provides the proper barriers that serialize
> concurrent waiter and waker.
>
> - Task wakeup is done in rcu read critical region, with a
> stable task pointer.
>
> - Because there is no concurrency among waiters, we need
> not worry about rcuwait_wait_event() calls corrupting
> the wait->task. As a consequence, this saves the locking
> done in swait when modifying the queue. This also applies
> to per-vcore wait for powerpc kvm-hv.
>
> The x86 tscdeadline_latency test mentioned in 8577370fb0cb
> ("KVM: Use simple waitqueue for vcpu->wq") shows that, on avg,
> latency is reduced by around 15-20% with this change.
>
> Cc: Paul Mackerras <paulus@...abs.org>
> Cc: kvmarm@...ts.cs.columbia.edu
> Cc: linux-mips@...r.kernel.org
> Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
Reviewed-by: Marc Zyngier <maz@...nel.org>
Thanks,
M.
--
Who you jivin' with that Cosmik Debris?
Powered by blists - more mailing lists