All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: John Ogness <john.ogness@linutronix.de>,
	"jbaron@akamai.com" <jbaron@akamai.com>,
	"mingo@redhat.com" <mingo@redhat.com>, kernel <kernel@axis.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Petr Mladek <pmladek@suse.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCH] dynamic debug: allow printing to trace event
Date: Thu, 23 Jul 2020 12:57:35 +0200	[thread overview]
Message-ID: <20200723105735.mqfkfbljjda7qz7n@axis.com> (raw)
In-Reply-To: <20200722112823.3ba72d31@oasis.local.home>

On Wed, Jul 22, 2020 at 05:28:23PM +0200, Steven Rostedt wrote:
> For you, I made this quick patch. If this works for you, I can make it
> into a formal patch. It includes a test use case in do_sys_openat2() to
> show the file name and file descriptor. Obviously, that wont be part of
> the final patch.

Thank you.  I had to replace the inline with an __attribute__((unused))
because otherwise my GCC errors out with "error: function
'find_vprintk_len' can never be inlined because it uses variable
argument lists".

Apart from that it works fine, but the several calls to vsnprintf() take
their toll and this method is twice as slow as the buffer-on-stack
implementation (and ftrace_vprintk()).  If I pass in a fixed size for
the __dynamic_array I get the same performance as the buffer-on-stack
method, but that's probably not surprising.

I know a dedicated trace event or a binary trace_printk() at the call
site of pr_debug() is always going to be more performant, but it would
be nice to avoid the extra slowdown if possible.

It's hard to guarantee that 256 bytes on the stack is safe on all
systems since these functions are called from lots of places.  

Would it be acceptable to just use a fixed size for the event?  At least
for my own debugging use cases it's preferable to just have to increase
the trace buffer size in case it's insufficient, rather than to have to
restort to one-off debugging code.

  reply	other threads:[~2020-07-23 11:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21 14:11 [PATCH] dynamic debug: allow printing to trace event Vincent Whitchurch
2020-07-21 21:30 ` Steven Rostedt
2020-07-22 11:37   ` Sergey Senozhatsky
2020-07-22 13:52   ` John Ogness
2020-07-22 14:49     ` Vincent Whitchurch
2020-07-22 15:28       ` Steven Rostedt
2020-07-23 10:57         ` Vincent Whitchurch [this message]
2020-07-23 15:26           ` Steven Rostedt
2020-08-14 13:34             ` Vincent Whitchurch
2020-07-22 15:25     ` Steven Rostedt
2020-07-23 14:02       ` John Ogness
2020-07-23 14:20         ` John Ogness
2020-07-23 15:39         ` Steven Rostedt

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=20200723105735.mqfkfbljjda7qz7n@axis.com \
    --to=vincent.whitchurch@axis.com \
    --cc=corbet@lwn.net \
    --cc=jbaron@akamai.com \
    --cc=john.ogness@linutronix.de \
    --cc=kernel@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    /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.