[lkml]   [2020]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] tracing: Resets the trace buffer after a snapshot
On Sun, 5 Jan 2020 05:31:13 -0500
"Frank A. Cancio Bello" <> wrote:

> Thank you both for your answers. I'm wondering what would be the reason
> for not resetting the trace buffer after it gets swapped with the snapshot
> buffer. Given that resetting it's not expensive, I would say that is not
> performance, so I'm intrigued ;)

Is it not expensive? It calls synchronize_rcu()! which is very

When I have used the snapshot buffer, It was usually to capture things
that happen at various times, but still look for the next trace. By
alternating, I do get to see where the last snapshot happened. It
basically doubles the size of the buffer.

> If it's OK, I will send two patches then, one documenting explicitly
> that the trace buffer it will not be reset after be swapped and the
> implications of this, and the second one changing the documentation of
> the field trace_array->max_buffer that I now realized that say:
> "
> /*
> ...
> * The buffers for the max_buffer are set up the same as the trace_buffer
> * When a snapshot is taken, the buffer of the max_buffer is swapped
> * with the buffer of the trace_buffer and the buffers are reset for
> * the trace_buffer so the tracing can continue.

It is reset partially by the latency tracers, and this is where it gets
confusing. Instead of a full reset, as the latency tracer only cares
about a specific start and end, it records where the start and end is,
and only modifies that. Look at the time_start of the trace_buffer.

Hmm, it may be possible to have an option just update that, which
should give the same effect.

-- Steve

 \ /
  Last update: 2020-01-06 18:42    [W:0.056 / U:29.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site