On Wed, 1 Jul 2026 13:04:04 +0100 David Laight <[email protected]> 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
