[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1gHKwPnw+vQ/irX@bombadil.infradead.org>
Date: Tue, 25 Oct 2022 08:56:27 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Miroslav Benes <mbenes@...e.cz>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel/params.c: defer most of param_sysfs_init() to
late_initcall time
On Tue, Oct 25, 2022 at 03:00:02PM +0200, Rasmus Villemoes wrote:
> param_sysfs_init(), and in particular param_sysfs_builtin() is rather
> time-consuming; for my board, it currently takes about 30ms.
>
> That amounts to about 3% of the time budget I have from U-Boot hands
> over control to linux and linux must assume responsibility for keeping
> the external watchdog happy.
>
> We must still continue to initialize module_kset at subsys_initcall
> time, since otherwise any request_module() would fail in
> mod_sysfs_init().
It would be good to document this through a comment.
> However, the bulk of the work in
> param_sysfs_builtin(), namely populating /sys/module/*/version and/or
> /sys/module/*/parameters/ for builtin modules, can be deferred to
> late_initcall time - there's no userspace yet anyway to observe
> contents of /sys or the lack thereof.
>
Other than that, this looks good and looks cautious enough.
Acked-by: Luis Chamberlain <mcgrof@...nel.org>
Happy to take this in through moduels and give this a spin on linux-next
to see what blows up early. Can you send a v2 with a small code comment for
the above?
Luis
Powered by blists - more mailing lists