linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: Re: tracer_init_tracefs really slow
Date: Wed, 9 Dec 2020 11:17:38 -0500	[thread overview]
Message-ID: <20201209111738.73944eac@gandalf.local.home> (raw)
In-Reply-To: <a7549324e3dcbacf2b52f8260fdf3a9a98e6171e.camel@pengutronix.de>

On Wed, 09 Dec 2020 15:38:50 +0100
Lucas Stach <l.stach@pengutronix.de> wrote:

> -	trace_eval_init();
> -
> ... and this. Moving the trace_eval_init into its own initcall means it
> gets started before tracer_init_tracefs. As it holds the
> trace_event_sem while updating the eval maps, event_trace_init() then
> blocks further initcall execution when it tries to grab this semaphore
> a bit down the line, killing the parallelism we are trying to unlock
> here.
> 
> With those 2 lines dropped, the change seems to work as intended and
> shaves ~830ms from the kernel boot time on this system.

Ah, the rationale to do that was so that it could start parsing earlier.
But you are right, if it's really slow, and is still parsing by the time we
start populating the tracefs directory, it will then cause that to block as
well.

OK, I wont move it into its own initcall and send a v2.

-- Steve

      reply	other threads:[~2020-12-09 16:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 16:16 tracer_init_tracefs really slow Lucas Stach
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 [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=20201209111738.73944eac@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).