On Wed, 1 Jul 2026 13:04:04 +0100
David Laight [off-list ref] wrote:

quoted

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