On Fri, 1 Mar 2024 11:37:54 -0500
Mathieu Desnoyers wrote:
> On 2024-03-01 10:49, Steven Rostedt wrote:
> > On Fri, 1 Mar 2024 13:37:18 +0800
> > linke wrote:
> >
> >>> So basically you are worried about read-tearing?
> >>>
> >>> That wasn't mentioned in the change log.
> >>
> >> Yes.
On 2024-03-01 10:49, Steven Rostedt wrote:
On Fri, 1 Mar 2024 13:37:18 +0800
linke wrote:
So basically you are worried about read-tearing?
That wasn't mentioned in the change log.
Yes. Sorry for making this confused, I am not very familiar with this and
still learning.
No problem. We all
On Fri, 1 Mar 2024 13:37:18 +0800
linke wrote:
> > So basically you are worried about read-tearing?
> >
> > That wasn't mentioned in the change log.
>
> Yes. Sorry for making this confused, I am not very familiar with this and
> still learning.
No problem. We all have to learn this anyway.
> So basically you are worried about read-tearing?
>
> That wasn't mentioned in the change log.
Yes. Sorry for making this confused, I am not very familiar with this and
still learning.
> Funny part is, if the above timestamp read did a tear, then this would
> definitely not match, and would
On Thu, 29 Feb 2024 20:32:26 +0800
linke wrote:
> Hi Steven, sorry for the late reply.
>
> >
> > Now the reason for the above READ_ONCE() is because the variables *are*
> > going to be used again. We do *not* want the compiler to play any games
> > with that.
> >
>
> I don't think it is
Hi Steven, sorry for the late reply.
>
> Now the reason for the above READ_ONCE() is because the variables *are*
> going to be used again. We do *not* want the compiler to play any games
> with that.
>
I don't think it is because the variables are going to be used again.
Compiler
Hi Steven, sorry for the late reply.
>
> Now the reason for the above READ_ONCE() is because the variables *are*
> going to be used again. We do *not* want the compiler to play any games
> with that.
>
I don't think it is because the variables are going to be used again.
Compiler
On Sun, 25 Feb 2024 15:03:02 -0500
Steven Rostedt wrote:
> *But* looking at this deeper, the commit_page may need a READ_ONCE()
> but not for the reason you suggested.
>
> commit_page = cpu_buffer->commit_page;
> commit_ts = commit_page->page->time_stamp;
>
> The commit_page
On Sun, 25 Feb 2024 11:05:06 +0800
linke li wrote:
> In function ring_buffer_iter_empty(), cpu_buffer->commit_page and
> curr_commit_page->page->time_stamp is read using READ_ONCE() in
> line 4354, 4355
>
> 4354curr_commit_page = READ_ONCE(cpu_buffer->commit_page);
> 4355curr_commit_ts
In function ring_buffer_iter_empty(), cpu_buffer->commit_page and
curr_commit_page->page->time_stamp is read using READ_ONCE() in
line 4354, 4355
4354curr_commit_page = READ_ONCE(cpu_buffer->commit_page);
4355curr_commit_ts = READ_ONCE(curr_commit_page->page->time_stamp);
while they are
10 matches
Mail list logo
