[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251009143748.GA2704@redhat.com>
Date: Thu, 9 Oct 2025 16:37:49 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Boqun Feng <boqun.feng@...il.com>,
David Howells <dhowells@...hat.com>, Ingo Molnar <mingo@...hat.com>,
Li RongQing <lirongqing@...du.com>,
Peter Zijlstra <peterz@...radead.org>,
Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] seqlock: introduce scoped_seqlock_read() and
scoped_seqlock_read_irqsave()
On 10/09, Linus Torvalds wrote:
>
> I'm batting zero. I still think it's true that this logic should be
> handled by the for-loop, but the *seq=1" hackery did actually do
> something.
Yes...
> But I think it means that "lockless" would have to be a "phase", and go 0/1/2.
OK, I like your version more than mine. In particular, the fact that it
puts seq/flags into the unsigned long data "union", somehow I didn't think
about this option. Plus, yes, it removes the "make/check seq is odd". Nice.
But do we really want to unroll the loop? This code should be optimized
for the likely case when the lockless pass succeeds.
Let me think a bit more before I send V3...
> #define __scoped_seqlock_read(lock, s, cond) \
> unrolled_full for (struct { unsigned long phase, data; } s = { 0 }; \
> s.phase < 3 && cond(lock, s.phase, &s.data); s.phase++)
I guess in your version "struct" doesn't buy too much, just saves one
__UNIQUE_ID(). But this is a matter of taste.
Thanks!
Oleg.
Powered by blists - more mailing lists