All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jessica Yu <jeyu@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Jonathan Corbet <corbet@lwn.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously
Date: Mon, 15 Mar 2021 20:21:09 +0000	[thread overview]
Message-ID: <20210315202109.GY4332@42.do-not-panic.com> (raw)
In-Reply-To: <20210313212528.2956377-2-linux@rasmusvillemoes.dk>

On Sat, Mar 13, 2021 at 10:25:27PM +0100, Rasmus Villemoes wrote:
> Most of the boot process doesn't actually need anything from the
> initramfs, until of course PID1 is to be executed. So instead of doing
> the decompressing and populating of the initramfs synchronously in
> populate_rootfs() itself, push that off to a worker thread.
> 
> This is primarily motivated by an embedded ppc target, where unpacking
> even the rather modest sized initramfs takes 0.6 seconds, which is
> long enough that the external watchdog becomes unhappy that it doesn't
> get attention soon enough. By doing the initramfs decompression in a
> worker thread, we get to do the device_initcalls and hence start
> petting the watchdog much sooner.
> 
> Normal desktops might benefit as well. On my mostly stock Ubuntu
> kernel, my initramfs is a 26M xz-compressed blob, decompressing to
> around 126M. That takes almost two seconds:
> 
> [    0.201454] Trying to unpack rootfs image as initramfs...
> [    1.976633] Freeing initrd memory: 29416K
> 
> Before this patch, these lines occur consecutively in dmesg. With this
> patch, the timestamps on these two lines is roughly the same as above,
> but with 172 lines inbetween - so more than one cpu has been kept busy
> doing work that would otherwise only happen after the
> populate_rootfs() finished.
> 
> Should one of the initcalls done after rootfs_initcall time (i.e.,
> device_ and late_ initcalls) need something from the initramfs (say, a
> kernel module or a firmware blob), it will simply wait for the
> initramfs unpacking to be done before proceeding, which should in
> theory make this completely safe.
> 
> But if some driver pokes around in the filesystem directly and not via
> one of the official kernel interfaces (i.e. request_firmware*(),
> call_usermodehelper*) that theory may not hold - also, I certainly
> might have missed a spot when sprinkling wait_for_initramfs(). So
> there is an escape hatch in the form of an initramfs_async= command
> line parameter.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>

  Luis

  reply	other threads:[~2021-03-15 20:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-13 21:25 [PATCH v3 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-03-13 21:25 ` [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously Rasmus Villemoes
2021-03-15 20:21   ` Luis Chamberlain [this message]
2021-03-15 21:33   ` Andrew Morton
2021-03-15 21:59     ` Rasmus Villemoes
2021-07-24  7:46   ` Alexander Egorenkov
2021-07-26 11:46     ` Rasmus Villemoes
2021-07-27  7:31       ` Bruno Goncalves
2021-07-27 13:54         ` Luis Chamberlain
2021-07-27 14:12           ` Bruno Goncalves
2021-07-27 14:21             ` Luis Chamberlain
2021-07-27 14:27               ` Bruno Goncalves
2021-07-27 14:42                 ` Luis Chamberlain
2021-07-27 14:48                   ` Bruno Goncalves
2021-07-28 10:44                   ` Alexander Egorenkov
2021-07-28 10:38           ` Alexander Egorenkov
2021-07-28 10:36       ` Alexander Egorenkov
2021-07-28 11:49         ` Rasmus Villemoes
2021-03-13 21:25 ` [PATCH v3 2/2] modules: add CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-03-15 20:06   ` Luis Chamberlain
2021-03-15 20:23 ` [PATCH v3 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH Luis Chamberlain

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=20210315202109.GY4332@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=ndesaulniers@google.com \
    --cc=tiwai@suse.de \
    --cc=torvalds@linux-foundation.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
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.