[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YsWZO3WM1WQzysIm@hirez.programming.kicks-ass.net>
Date: Wed, 6 Jul 2022 16:16:27 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Waiman Long <longman@...hat.com>
Cc: Nicholas Piggin <npiggin@...il.com>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/13] locking/qspinlock: merge qspinlock_paravirt.h into
qspinlock.c
On Wed, Jul 06, 2022 at 09:35:48AM -0400, Waiman Long wrote:
> On 7/5/22 13:20, Peter Zijlstra wrote:
> > On Tue, Jul 05, 2022 at 12:38:13AM +1000, Nicholas Piggin wrote:
> > > There isn't much reason to keep these separate.
> > The reason was so that other paravirt implementations could be added.
> >
> > The CNA thing was also implemented this way...
>
> Do you have any plan to take CNA [1] some time in the future?
I do mean to look at it, but somehow I never get around to it :-(
ISTR the O(n) on unlock got fixed.
Also; and I think this is why it never really gets to the top of the
todo list, I do still feel it is fixing the wrong problem. IIRC the
whole reason for CNA is the futex hash lock and I think that a better
futex ABI would be a *much* better solution there.
> Anyway, the main reason the paravirt code is separated into a separated file
> is to leave only the core part in qspinlock.c so that new users are
> overwhelmed with the messy details for the paravirt code. Putting everything
> into a single can make it harder to read for the newbies.
>
> Also eliminating the preprocessor trick will make it harder to integrate a
> different qspinlock variant, like CNA, into the code base.
Fixed that already: YsR8BIyrSCQ8AlEo@...ktop.programming.kicks-ass.net
Powered by blists - more mailing lists