All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Masami Hiramatsu" <mhiramat@kernel.org>,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	"Michal Koutný" <mkoutny@suse.com>
Subject: Re: [PATCH 2/2] tracing: Keep pid and comm[] in the same structure
Date: Wed, 1 Jul 2026 17:52:05 +0100	[thread overview]
Message-ID: <20260701175205.7d1a8cb6@pumpkin> (raw)
In-Reply-To: <20260701082340.5b0bd4e7@gandalf.local.home>

On Wed, 1 Jul 2026 08:23:40 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> 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.
> 

Mostly thoughts about the size of the cache and the difference between the
apparent default size of 128 and the actual size of 6300.

I had said that I'd not really looked at when it was used, just what
it contained.

None of that is relevant to this patch which just changes the data structures
a bit.
It also means that most updates will only dirty a single cache line.
Indeed it is probably worth comparing the comm[] strings and only doing
the write it they differ to avoid dirtying the cache line(s).

	David



      reply	other threads:[~2026-07-01 16:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 21:23 [PATCH rfc 0/2] Improvements to ftrace comm[] handling David Laight
2026-06-26 21:23 ` [PATCH 1/2] tracing: Embed 'char comm[16]' in a structure David Laight
2026-06-29 20:26   ` Steven Rostedt
2026-06-30  9:26     ` David Laight
2026-06-26 21:23 ` [PATCH 2/2] tracing: Keep pid and comm[] in the same structure David Laight
2026-06-29 20:49   ` Steven Rostedt
2026-06-30 10:01     ` David Laight
2026-06-30 19:03       ` Steven Rostedt
2026-07-01 10:04         ` David Laight
2026-07-01 10:38           ` Steven Rostedt
2026-07-01 12:04             ` David Laight
2026-07-01 12:23               ` Steven Rostedt
2026-07-01 16:52                 ` David Laight [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260701175205.7d1a8cb6@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.