[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjXae3b7nOf8bEHtzRcQAZGQFe2EbvXDxg_V42h8AraHA@mail.gmail.com>
Date: Thu, 9 Oct 2025 09:18:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
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 Thu, 9 Oct 2025 at 07:39, Oleg Nesterov <oleg@...hat.com> wrote:
>
> But do we really want to unroll the loop? This code should be optimized
> for the likely case when the lockless pass succeeds.
Dropping the unroll magic certainly makes the patch more palatable,
and maybe it doesn't matter that much.
It really was mainly me going "this should be easy for the compiler to
see the flow statically", and the need to keep two state variables
annoyed me.
But I guess many of the users are complicated enough that you actually
don't want to have two copies of the inner body. If they weren't
complicated, they'd just use the simpler
do { } while (read_seqcount_retry(...));
model.
So you are right, I was probably chasing that optimal code generation
for no real reason.
Linus
Powered by blists - more mailing lists