LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: tracer_init_tracefs really slow
Date: Mon, 07 Sep 2020 18:16:52 +0200
Message-ID: <68d7b3327052757d0cd6359a6c9015a85b437232.camel@pengutronix.de> (raw)

Hi all,

one of my colleagues has taken a look at device boot times and stumbled
across a pretty big amount of kernel boot time being spent in
tracer_init_tracefs(). On this particular i.MX6Q based device the
kernel spends more than 1 second in this function, which is a
significant amount of the overall kernel inititalization time. While
this machine is no rocket with its Cortex A9 @ 800MHz, the amount of
CPU time being used there is pretty irritating.

Specifically the issue lies within trace_event_eval_update where ~1100
trace_event_calls get updated with ~500 trace_eval_maps. I haven't had
a chance yet to dig any deeper or try to understand more of what's
going on there, but I wanted to get the issue out there in case anyone
has some cycles to spare to help us along.

The obvious questions for now are:
1. Why is this function so damn expensive (at least on this whimpy ARM
machine)? and
2. Could any of this be done asynchronously, to not block the kernel in
early init?

Regards,
Lucas


             reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 16:16 Lucas Stach [this message]
2020-12-04  2:18 ` Steven Rostedt
2020-12-07 16:24   ` Lucas Stach
2020-12-07 16:47     ` Steven Rostedt
2020-12-07 19:47     ` Steven Rostedt
2020-12-09 14:38       ` Lucas Stach
2020-12-09 16:17         ` 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=68d7b3327052757d0cd6359a6c9015a85b437232.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git