Re: [PATCH] tracing: Update snapshot buffer on resize if it is allocated

[Steven Rostedt]

On Mon, 11 Dec 2023 21:31:34 +0900
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote:

> On Sun, 10 Dec 2023 22:54:47 -0500
> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
> > From: "Steven Rostedt (Google)" <rostedt@xxxxxxxxxxx>
> > 
> > The snapshot buffer is to mimic the main buffer so that when a snapshot is
> > needed, the snapshot and main buffer are swapped. When the snapshot buffer
> > is allocated, it is set to the minimal size that the ring buffer may be at
> > and still functional. When it is allocated it becomes the same size as the
> > main ring buffer, and when the main ring buffer changes in size, it should
> > do.  
> 
> nit: There seems two "when the snapshot buffer is allocated" case, maybe latter
> "it" means main buffer?

I changed the paragraph to be:

    The snapshot buffer is to mimic the main buffer so that when a snapshot is
    needed, the snapshot and main buffer are swapped. When the snapshot buffer
    is allocated, it is set to the minimal size that the ring buffer may be at
    and still functional. When it is allocated it becomes the same size as the
    main ring buffer, and when the main ring buffer changes in size, the
    snapshot should also change in size if it is allocated.

> 
> > 
> > Currently, the resize only updates the snapshot buffer if it's used by the
> > current tracer (ie. the preemptirqsoff tracer). But it needs to be updated
> > anytime it is allocated.
> > 
> > When changing the size of the main buffer, instead of looking to see if
> > the current tracer is utilizing the snapshot buffer, just check if it is
> > allocated to know if it should be updated or not.
> > 
> > Also fix typo in comment just above the code change.
> >   
> 
> Looks good to me.
> 
> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>

Thanks!

> 
> BTW, the historical naming leads this kind of issues.
> Maybe we'd better to rename 'max_buffer' to 'snapshot_buffer'?

Agreed. But that's a cleanup for another day. Hmm, maybe that too should be
marked as "KTODO"?

  https://lore.kernel.org/all/369bc919-1a1d-4f37-9cc9-742a86a41282@kadam.mountain/


There's a lot of things that we have been discussing on these ring-buffer
patches that could be KTODO items.

-- Steve