From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis Chamberlain <mcgrof@kernel.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 Mailing List <linux-kernel@vger.kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH v2 1/2] init/initramfs.c: allow asynchronous unpacking
Date: Thu, 11 Mar 2021 01:17:56 +0100 [thread overview]
Message-ID: <2a33d478-b7a8-5b3c-7bc5-f33eb27b44fa@rasmusvillemoes.dk> (raw)
In-Reply-To: <CAHk-=wgfMQyYSkdRkCuHOQEcvoyw=fN7q+0cU-s9dNqDHkSmrw@mail.gmail.com>
On 09/03/2021 23.16, Linus Torvalds wrote:
> On Tue, Mar 9, 2021 at 1:17 PM Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>>
>> So add an initramfs_async= kernel parameter, allowing the main init
>> process to proceed to handling device_initcall()s without waiting for
>> populate_rootfs() to finish.
>
> Oh, and a completely unrelated second comment about this: some of the
> initramfs population code seems to be actively written to be slow.
>
> For example, I'm not sure why that write_buffer() function uses an
> array of indirect function pointer actions. Even ignoring the whole
> "speculation protections make that really slow" issue that came later,
> it seems to always have been actively (a) slower and (b) more complex.
>
> The normal way to do that is with a simple switch() statement, which
> makes the compiler able to do a much better job. Not just for the
> state selector - maybe it picks that function pointer approach, but
> probably these days just direct comparisons - but simply to do things
> like inline all those "it's used in one place" cases entirely. In
> fact, at that point, a lot of the state machine changes may end up
> turning into pure goto's - compilers are sometimes good at that
> (because state machines have often been very timing-critical).
FWIW, I tried doing
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -401,24 +401,26 @@ static int __init do_symlink(void)
return 0;
}
-static __initdata int (*actions[])(void) = {
- [Start] = do_start,
- [Collect] = do_collect,
- [GotHeader] = do_header,
- [SkipIt] = do_skip,
- [GotName] = do_name,
- [CopyFile] = do_copy,
- [GotSymlink] = do_symlink,
- [Reset] = do_reset,
-};
-
static long __init write_buffer(char *buf, unsigned long len)
{
+ int ret;
+
byte_count = len;
victim = buf;
- while (!actions[state]())
- ;
+ do {
+ switch (state) {
+ case Start: ret = do_start(); break;
+ case Collect: ret = do_collect(); break;
+ case GotHeader: ret = do_header(); break;
+ case SkipIt: ret = do_skip(); break;
+ case GotName: ret = do_name(); break;
+ case CopyFile: ret = do_copy(); break;
+ case GotSymlink: ret = do_symlink(); break;
+ case Reset: ret = do_reset(); break;
+ }
+ } while (!ret);
+
return len - byte_count;
}
and yes, all the do_* functions get inlined into write_buffer with some
net space saving:
add/remove: 0/9 grow/shrink: 1/0 up/down: 1696/-2112 (-416)
Function old new delta
write_buffer 100 1796 +1696
actions 32 - -32
do_start 52 - -52
do_reset 112 - -112
do_skip 128 - -128
do_collect 144 - -144
do_symlink 172 - -172
do_copy 304 - -304
do_header 572 - -572
do_name 596 - -596
Total: Before=5360, After=4944, chg -7.76%
(ppc32 build). But the unpacking still takes the same time. It might be
different on x86.
Rasmus
next prev parent reply other threads:[~2021-03-11 0:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 14:29 [PATCH/RFC 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-02-24 14:29 ` [PATCH/RFC 1/2] init/initramfs.c: allow asynchronous unpacking Rasmus Villemoes
2021-02-24 17:17 ` Linus Torvalds
2021-02-24 22:13 ` Rasmus Villemoes
2021-02-24 17:58 ` kernel test robot
2021-02-24 21:37 ` kernel test robot
2021-02-24 22:09 ` kernel test robot
2021-03-02 16:26 ` Luis Chamberlain
2021-02-24 14:29 ` [PATCH/RFC 2/2] modules: add CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-02-24 22:19 ` [PATCH/RFC 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-03-09 21:16 ` [PATCH v2 " Rasmus Villemoes
2021-03-09 21:16 ` [PATCH v2 1/2] init/initramfs.c: allow asynchronous unpacking Rasmus Villemoes
2021-03-09 22:07 ` Linus Torvalds
2021-03-09 22:39 ` Rasmus Villemoes
2021-03-11 17:55 ` Luis Chamberlain
2021-03-11 17:55 ` Luis Chamberlain
2021-03-09 22:16 ` Linus Torvalds
2021-03-09 22:51 ` Rasmus Villemoes
2021-03-11 0:17 ` Rasmus Villemoes [this message]
2021-03-11 1:45 ` Rasmus Villemoes
2021-03-11 18:02 ` Linus Torvalds
2021-03-13 13:13 ` Rasmus Villemoes
2021-03-09 21:17 ` [PATCH v2 2/2] modules: add CONFIG_MODPROBE_PATH Rasmus Villemoes
2021-03-10 9:46 ` Greg Kroah-Hartman
2021-03-11 13:28 ` Jessica Yu
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=2a33d478-b7a8-5b3c-7bc5-f33eb27b44fa@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--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=mcgrof@kernel.org \
--cc=ndesaulniers@google.com \
--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.