On Thu, 2025-06-26 at 19:47 +0206, John Ogness wrote:
> Hi Steven,
>
> On 2025-06-26, Steven Rostedt <rost...@goodmis.org> wrote:
> > > Your scenario can still happen despite the memory barrier:
> >
> > Yes, but the point isn't really to prevent the race. It's more
> > about making
> > the race window smaller.
> >
> > When we disable it, if something is currently using it then it may
> > or may
> > not get in. That's fine as this isn't critical.
> >
> > But from my understanding, without the barriers, some architectures
> > may
> > never see the update. That is, the write from one CPU may not get
> > to memory
> > for a long time and new incoming readers will still see the old
> > data. I'm
> > more concerned with new readers than ones that are currently racing
> > with
> > the updates.
>
> Memory barriers do not affect visibility. They only affect ordering.
> And
> ordering implies that there are at least 2 pieces of data involved. A
> memory barrier has no meaning when you are only talking about 1 piece
> of
> data (in this case @buffer_disabled).
>
> For example, update_traceon_count() has an smp_rmb()/smp_wmb() pair
> to
> make sure @count updates are ordered to be after @buffer_disabled
> updates.
>
> read(count)
> smp_rmb()
> read(buffer_disabled)
>
> write(buffer_disabled)
> smp_wmb()
> write(count)
>
> But what exactly are the memory barriers removed in this patch
> ordering?
>
Hi all,
these statements made me curious: I always thought of memory barriers as a way
to order reads and writes to the same address across different CPUs (in other
words, for visibility).
For instance I'd do something like:
CPU 1 CPU2
write(x)
smp_mb()
<implicit paired barrier>
READ_ONCE(x)
Now, I get there isn't much we can do if reader and writer are racing, but, as
Steve said, I'm expecting the presence of barriers to make the racing window
smaller.
Am I misinterpreting the whole thing here? Are those barriers just ordering
reads with reads and writes with writes (hence useful only with multiple
variables)?
Thanks,
Gabriele
