From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55A33C433FE for ; Mon, 7 Dec 2020 16:48:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1145023787 for ; Mon, 7 Dec 2020 16:48:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727922AbgLGQry (ORCPT ); Mon, 7 Dec 2020 11:47:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:43054 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725804AbgLGQrx (ORCPT ); Mon, 7 Dec 2020 11:47:53 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D0BFD23877; Mon, 7 Dec 2020 16:47:12 +0000 (UTC) Date: Mon, 7 Dec 2020 11:47:11 -0500 From: Steven Rostedt To: Lucas Stach Cc: Ingo Molnar , linux-kernel@vger.kernel.org, kernel@pengutronix.de Subject: Re: tracer_init_tracefs really slow Message-ID: <20201207114711.0748b19c@gandalf.local.home> In-Reply-To: <31a0d6b7cf7326e7e2f55ab2b668defb0c10b140.camel@pengutronix.de> References: <68d7b3327052757d0cd6359a6c9015a85b437232.camel@pengutronix.de> <20201203211854.7e5caa49@oasis.local.home> <31a0d6b7cf7326e7e2f55ab2b668defb0c10b140.camel@pengutronix.de> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 07 Dec 2020 17:24:58 +0100 Lucas Stach wrote: > > We could make a thread that does this, that the init wakes up and runs, > > letting the kernel to move forward. Would you like to make that patch > > or shall I? > > I guess you are much more likely to come up with a correct patch, as > I'm not really clear yet on when we would need to synchronize this > thread, to make sure things are available before they get used by > something. I likely won't have time in the near future to read enough > code in this particular spot of the kernel. No problem. I've just been told to try to delegate when I can ;-) > > I would be happy to test a patch on our whimpy machines, though. :) The code is only needed for user space, and we can make it a separate thread to do the work to let kernel move forward. The code is wrapped with a mutex so that even if it's still processing when user space is up and running, and it tries to access the code, it should block until it's finished as well. I'll write something up and send it to you. Thanks for the report! -- Steve