[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200330110855.437fe854@gandalf.local.home>
Date: Mon, 30 Mar 2020 11:08:55 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: David Laight <David.Laight@...LAB.COM>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ftrace not showing the process names for all processes on
syscall events
On Mon, 30 Mar 2020 14:28:01 +0000
David Laight <David.Laight@...LAB.COM> wrote:
> I've just updated one of my systems to 5.6.0-rc7+ (end of last week).
> ftrace in showing <...>-3179 in the system call events for a couple
> of threads of the active processes.
> Other threads of the same processes are fine.
> The scheduler process switch events also show the full name.
>
> Is this a known regression?
Well, that code hasn't changed in years. But can you explain more of what
you did? Was this the "trace" file, or "trace_pipe" file? The command names
are cached in an array (see /sys/kernel/tracing/saved_cmdlines) of the size
that is defined by the saved_cmdlines_size file.
The cmdlines get updated via the sched_switch and sched_waking trace
events. The update is protected by a spinlock, which is only taken with a
"trylock", if the lock fails, then it does not get updated (we don't want
to hold back the running code just to cache the name of an event), but it
will try at the next sched event until it succeeds. This means that under
strong contention, it may fail to cache certain names.
This is not a regression, it's really just the work load that can cause
event names to be missed. I could work on something that if you have the
sched events enabled, that the output side could do its own caching to get
better results.
-- Steve
Powered by blists - more mailing lists