From: Rasmus Villemoes <firstname.lastname@example.org> To: Andrew Morton <email@example.com>, Rasmus Villemoes <firstname.lastname@example.org> Cc: Luis Chamberlain <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, Jessica Yu <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, Jonathan Corbet <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, email@example.com, Nick Desaulniers <firstname.lastname@example.org> Subject: Re: [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously Date: Mon, 15 Mar 2021 22:59:52 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 15/03/2021 22.33, Andrew Morton wrote: > On Sat, 13 Mar 2021 22:25:27 +0100 Rasmus Villemoes <email@example.com> 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 seems sensible. And nice. Thanks. > Are you sure that you've found all the code paths that require that > initramfs be ready? You have one in init/main, one in the bowels of > the firmware loader and one in UML. How do we know that there are no > other such places? No, I don't _know_ that I've found all such places, but nobody, Linus included, have been able to come up with any that I've missed. At this point, the only way to figure it out is to get the code into linux-next (and the more time it gets before the merge window, the better). Since it's default-on, it should get quite a bit of testing that way. > Also, all this doesn't buy anything for uniprocessor machines. Is > there a simple way of making it all go away if !CONFIG_SMP? It absolutely does buy something for UP, at least for some special case: The ppc machine I'm talking about is UP, and without getting the initramfs unpacking pushed to the background, the machine doesn't get to pet the external hardware watchdog soon enough. So this is really the difference between booting successfully or being a power-consuming paper weight. Also, lots of device initialization actually makes the CPU twiddle its thumbs now and then, so having something other than the idle thread to schedule makes better use of the single CPU. Rasmus
next prev parent reply other threads:[~2021-03-15 22:00 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 2021-03-15 21:33 ` Andrew Morton 2021-03-15 21:59 ` Rasmus Villemoes [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously' \ /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
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.