Re: [PATCH 2/2] tracing: Keep pid and comm[] in the same structure

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 1 Jul 2026 13:04:04 +0100
David Laight <david.laight.linux@gmail.com> wrote:


> > Well, that would break trace-cmd. As reading the raw buffers clears the
> > trace, and trace-cmd reads the saved_cmdlines file *after* it reads the
> > trace, as during the trace it gets populated.  
> 
> So you'd need to clear it when tracing is enabled after the buffer is cleared.
> Just a matter of getting the timing right.

Why? Note, saved_cmdlines is for *all* instances. You can have multiple
instances tracing different things and they still all use the one
saved_cmdlines file. It's not tied to any specific buffer. It's a cache. It
gets populated at the next schedule switch after an event occurs.

> 
> If trace-cmd is currently given all 6000 entries (if you've run tracing for
> long enough), then giving it all the active processes isn't going to be any
> more of a problem.

I'm much more concerned about losing processes that were traced! A lot of
tracing happens to tasks while running hackbench. Hackbench isn't being
traced, but if we record it, it will blow away all the cache and we lose
the task names we care about.

> So you could just save comm[] in the process exit path when the trace buffer
> is non-empty, or better those started before tracing was last stopped.

Again, which tracer? You can have multiple instances.

> You'd need to give trace-cmd the active ones first and delete the entry
> from the cache because the pid might have been reused.
> 
> All just needs some coding, testing, and fixing of corner cases.

What exactly are you trying to solve? This hasn't been perfect, but it's
been good enough since 2009.

-- Steve