linux-kernel - Re: Boot-time initiative (SIG) thoughts and next steps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <932f1203-ec01-4a58-9281-ef83e537d62c@landley.net>
Date: Sat, 26 Oct 2024 13:50:52 -0500
From: Rob Landley <rob@...dley.net>
To: Saravana Kannan <saravanak@...gle.com>, "Bird, Tim" <Tim.Bird@...y.com>
Cc: "linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Boot-time initiative (SIG) thoughts and next steps

On 10/26/24 02:36, Saravana Kannan wrote:
> On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@...y.com> wrote:
>>
>> Hey Linux developers,
>>
>> The response to my request to form a Special Interest Group for boot-time reduction
>> for Linux has been really great.  Many people contacted me by e-mail and on LinkedIn.
> 
> Hi Tim,
> 
> Thanks for organizing this and moving it forward! I'd be interested in
> contributing to this effort as a lot of work I have done aligns with
> the goals of this effort and boot time is of obvious value to Android.

I'm kind of an edge case for this project because my mkroot images at 
https://landley.net/bin/mkroot/latest mostly boot up in a couple 
seconds. (And faster if you feed in KARGS=quiet so the kernel boot 
messages don't take time emitting and scrolling before interrupts have 
been enabled. Although "quiet" doesn't seem to work in current vanilla 
kernels...?)

The ones that _don't_ are generally because qemu's bios for that 
platform twiddles its thumbs for a long time before launching the 
kernel, although there are some slow drivers in there:

$ for i in powerpc m68k i686 s390x; do (cd $i && echo $i && KARGS='quiet 
HANDOFF=echo' bash -c 'time ./run-qemu.sh > /dev/null'); done

powerpc
real	0m6.154s
user	0m3.689s
sys	0m0.341s

m68k
real	0m4.220s
user	0m1.142s
sys	0m0.212s

i686
real	0m1.986s
user	0m1.709s
sys	0m0.209s

s390x
real	0m1.644s
user	0m1.378s
sys	0m0.228s

And that's with qemu running on a 10 year old laptop that I'll have to 
switch off of when debian drops x86-64-v2 support. (Even that i686 test 
isn't kvm.) It's running a recent-ish kernel (binaries I had lying 
around)...

# cat /proc/version
Linux version 6.11.0-rc7 (landley@...ftwood) (s390x-linux-musl-gcc (GCC) 
11.4.0, GNU ld (GNU Binutils) 2.33.1) #1 SMP Sat Sep 14 01:36:19 CDT 2024

Built using the kernel config files in the "doc" directory of those 
tarballs.

Are you trying to optimize the kernel boot, or more trying to optimize 
userspace? Because my userspace init is just a small shell script:

https://github.com/landley/toybox/blob/master/mkroot/mkroot.sh#L102

And the above simple test loop just told that to run "echo" instead of 
/bin/sh so I could easily collect boot-and-exit timing for the qemu 
process...

>> I had hoped to push out a script today to start to gather data on boot-time on different
>> platforms, for people to run who had expressed interest in helping with this effort. But
>> I got overwhelmed with other tasks, and I may not get it done today.  I'll be in Tokyo next
>> week for Open Source Summit Japan.  If you are there, please try to catch me and say hi.
>> Given that, I'll see how soon I can provide the script I'm talking about, and we can
>> discuss the goals and design of the script.

I regression test under qemu because it gives reproducibly scriptable 
results. I've even got plumbing to run canned tests on multiple 
architectures in parallel (part of my release testing):

https://github.com/landley/toybox/blob/master/mkroot/testroot.sh

Rob