[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241024095659.GD9767@noisy.programming.kicks-ass.net>
Date: Thu, 24 Oct 2024 11:56:59 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, linux-trace-kernel@...r.kernel.org,
linux-mm@...ck.org, oleg@...hat.com, rostedt@...dmis.org,
mhiramat@...nel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, jolsa@...nel.org, paulmck@...nel.org,
willy@...radead.org, akpm@...ux-foundation.org, mjguzik@...il.com,
brauner@...nel.org, jannh@...gle.com, mhocko@...nel.org,
vbabka@...e.cz, shakeel.butt@...ux.dev, hannes@...xchg.org,
Liam.Howlett@...cle.com, lorenzo.stoakes@...cle.com
Subject: Re: [PATCH v3 tip/perf/core 1/4] mm: introduce
mmap_lock_speculation_{start|end}
On Wed, Oct 23, 2024 at 03:17:01PM -0700, Suren Baghdasaryan wrote:
> > Or better yet, just use seqcount...
>
> Yeah, with these changes it does look a lot like seqcount now...
> I can take another stab at rewriting this using seqcount_t but one
> issue that Jann was concerned about is the counter being int vs long.
> seqcount_t uses unsigned, so I'm not sure how to address that if I
> were to use seqcount_t. Any suggestions how to address that before I
> move forward with a rewrite?
So if that issue is real, it is not specific to this case. Specifically
preemptible seqcount will be similarly affected. So we should probably
address that in the seqcount implementation.
Powered by blists - more mailing lists