[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230921140406.GF14803@noisy.programming.kicks-ass.net>
Date: Thu, 21 Sep 2023 16:04:06 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Boqun Feng <boqun.feng@...il.com>, Ingo Molnar <mingo@...hat.com>,
Rik van Riel <riel@...riel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Waiman Long <longman@...hat.com>,
Will Deacon <will@...nel.org>,
Alexey Gladkov <legion@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] seqlock: simplify SEQCOUNT_LOCKNAME()
On Thu, Sep 21, 2023 at 01:48:26PM +0200, Oleg Nesterov wrote:
> On 09/16, Peter Zijlstra wrote:
> >
> > On Wed, Sep 13, 2023 at 05:49:53PM +0200, Oleg Nesterov wrote:
> > > 1. Kill the "lockmember" argument. It is always s->lock plus
> > > __seqprop_##lockname##_sequence() already uses s->lock and
> > > ignores "lockmember".
> > >
> > > 2. Kill the "lock_acquire" argument. __seqprop_##lockname##_sequence()
> > > can use the same "lockbase" prefix for _lock and _unlock.
> > >
> > > Apart from line numbers, gcc -E outputs the same code.
> >
> > With seqlock_ww_mutex gone, yes this is a nice cleanup.
>
> Thanks.
>
> Can you look at 2/5? To me it looks like a good cleanup too.
> I am going to resend 1/5 and 2/5, as no one is interested in
> stats_lock change.
2 seems okay. Will need a new changelog without the rest thouhg. Perhaps
talk about how it perserves the constness instead?
Powered by blists - more mailing lists