Thread (13 messages) 13 messages, 5 authors, 2025-07-22

Re: [PATCH] tracing: Remove pointless memory barriers

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2025-06-26 16:34:22
Also in: lkml

On Thu, 26 Jun 2025 18:04:59 +0200
Nam Cao [off-list ref] wrote:
I think you have it inverted? I assume you meant:

"Without the barriers, the tr->buffer_disabled = 1 can be set on one CPU,
and the other CPU can think the buffer is still enabled and do work that
will end up doing nothing."

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.
CPU1                          CPU2
                              smp_rb()
                              read buffer_disabled, see 0 --> let's do work!
buffer_disabled=1
smp_wb()
                              do work -> end up doing nothing
quoted
From my understanding, smp_wb()'s purpose is ensuring the ordering of one  
write and another write, e.g.:
    write(a)
    smp_wb()
    write(b)

For our case, there is only a single write. Therefore I don't think
smp_wb() is useful.
Well, it does make it visible for other CPUs that do not have strong cache
coherency.

-- Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help