[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200708083210.GD597537@hirez.programming.kicks-ass.net>
Date: Wed, 8 Jul 2020 10:32:10 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Waiman Long <longman@...hat.com>
Cc: Nicholas Piggin <npiggin@...il.com>, linuxppc-dev@...ts.ozlabs.org,
Anton Blanchard <anton@...abs.org>,
Boqun Feng <boqun.feng@...il.com>, kvm-ppc@...r.kernel.org,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
virtualization@...ts.linux-foundation.org,
Will Deacon <will@...nel.org>
Subject: Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks
On Tue, Jul 07, 2020 at 11:33:45PM -0400, Waiman Long wrote:
> From 5d7941a498935fb225b2c7a3108cbf590114c3db Mon Sep 17 00:00:00 2001
> From: Waiman Long <longman@...hat.com>
> Date: Tue, 7 Jul 2020 22:29:16 -0400
> Subject: [PATCH 2/9] locking/pvqspinlock: Introduce
> CONFIG_PARAVIRT_QSPINLOCKS_LITE
>
> Add a new PARAVIRT_QSPINLOCKS_LITE config option that allows
> architectures to use the PV qspinlock code without the need to use or
> implement a pv_kick() function, thus eliminating the atomic unlock
> overhead. The non-atomic queued_spin_unlock() can be used instead.
> The pv_wait() function will still be needed, but it can be a dummy
> function.
>
> With that option set, the hybrid PV queued/unfair locking code should
> still be able to make it performant enough in a paravirtualized
How is this supposed to work? If there is no kick, you have no control
over who wakes up and fairness goes out the window entirely.
You don't even begin to explain...
Powered by blists - more mailing lists