Boot-time initiative (SIG) thoughts and next steps

Boot-time initiative (SIG) thoughts and next steps

[Bird, Tim]

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.

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.

A couple of quick things:
There are lots of things to discuss, but here are a few things to get started with...

= wiki account =
The wiki where we'll be maintaining information about 
boot time, and about activities of the boot time SIG, is the elinux wiki.
The page we'll be focusing on is: https://elinux.org/Boot_Time.
If you are interested in helping update and maintain the information there
(which I hope almost everyone is), then please make sure you have a user
account on the wiki.
If you don't have one, please go here:
https://elinux.org/Special:RequestAccount
I have to manually approve accounts in order to fight spambots.  It might
take a few days for me to get to your request.  It's very helpful if you
put a comment in one of the request fields about this being related to
the boot-time initiative or SIG, so I can distinguish your request from
spam requests.

= support for new developers =
A number of developers have asked me if they can participate and contribute,
even if they are not seasoned Linux kernel developers.  The answer is "Yes"!
I hope to provide a range of activities for people to provide data, help update
the wiki, implement and run tests and perform research - even if they don't have
any previous Linux development experience.  I hope it will be fun to participate,
and very educational.

If you are new to Linux and have just joined this group, please review some
of the material on the Boot_Time page mentioned above.  We will be covering
more than just the kernel in the project, but one place to get started will be
to look at the kernel source file init/main.c, particularly the function start_kernel()
(which is where a lot of the "magic" happens at kernel startup time.)
Don't be afraid to ask questions.  Please ask them on this list so that others benefit
from any answers provided.

= short-term plans =
I am building out the "membership" of the SIG over the very short term.  I have
some more individuals and companies to contact to see who wants to be involved.

Other things I'd like to do are:
 * start gathering boot timing data for different systems (using the script I described above)
 * start pruning obsolete information and refactoring the boot-time material on the elinux wiki
    * (Yes - some of the material there is quite dated, so be sure to check it out before you try to
       use some tool or technique - if something doesn't work, please send an e-mail or mark it in the wiki)
 * discuss planning for SIG video conference calls and meetings
     * I know I'm interested in having a boot-time micro-conference at Embedded Linux
     Conference next year - but we need to discuss if we want regular calls or other face-to-face
      meetings
 * perform a survey of existing boot-time reduction techniques, and see where they are
    in the pipeline of upstreaming or deployment in actual products
 * finally (for this list), brainstorm what activities the SIG should do, and how we can
    collaborate on those.  I've started a list at: https://elinux.org/Boot_Time_Project_Ideas
    that you can look at and comment on (either on this list, or on the wiki).

I'll be busy with business travel and Sony work next week, but I hope I still
find some time to follow up on this .  I look forward to working with many of you
reading this, on improving this area of Linux.
 -- Tim

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

[Saravana Kannan]

On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.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 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.
>
> A couple of quick things:
> There are lots of things to discuss, but here are a few things to get started with...
>
> = wiki account =
> The wiki where we'll be maintaining information about
> boot time, and about activities of the boot time SIG, is the elinux wiki.
> The page we'll be focusing on is: https://elinux.org/Boot_Time.
> If you are interested in helping update and maintain the information there
> (which I hope almost everyone is), then please make sure you have a user
> account on the wiki.
> If you don't have one, please go here:
> https://elinux.org/Special:RequestAccount
> I have to manually approve accounts in order to fight spambots.  It might
> take a few days for me to get to your request.  It's very helpful if you
> put a comment in one of the request fields about this being related to
> the boot-time initiative or SIG, so I can distinguish your request from
> spam requests.

Can we instead keep this all a part of the kernel docs instead of the
wiki? Couple of reasons for that:
- Since the instructions can be kernel version specific (as things
change), it makes sense to have the document synced with the kernel.
- It's one less account to maintain and less chores for you.
- One less business approval to get in terms of contributing to
external sources.
- Less chance of bit rot. As people make changes, the docs are right
there to go fix.

Thanks,
Saravana

> = support for new developers =
> A number of developers have asked me if they can participate and contribute,
> even if they are not seasoned Linux kernel developers.  The answer is "Yes"!
> I hope to provide a range of activities for people to provide data, help update
> the wiki, implement and run tests and perform research - even if they don't have
> any previous Linux development experience.  I hope it will be fun to participate,
> and very educational.
>
> If you are new to Linux and have just joined this group, please review some
> of the material on the Boot_Time page mentioned above.  We will be covering
> more than just the kernel in the project, but one place to get started will be
> to look at the kernel source file init/main.c, particularly the function start_kernel()
> (which is where a lot of the "magic" happens at kernel startup time.)
> Don't be afraid to ask questions.  Please ask them on this list so that others benefit
> from any answers provided.
>
> = short-term plans =
> I am building out the "membership" of the SIG over the very short term.  I have
> some more individuals and companies to contact to see who wants to be involved.
>
> Other things I'd like to do are:
>  * start gathering boot timing data for different systems (using the script I described above)
>  * start pruning obsolete information and refactoring the boot-time material on the elinux wiki
>     * (Yes - some of the material there is quite dated, so be sure to check it out before you try to
>        use some tool or technique - if something doesn't work, please send an e-mail or mark it in the wiki)
>  * discuss planning for SIG video conference calls and meetings
>      * I know I'm interested in having a boot-time micro-conference at Embedded Linux
>      Conference next year - but we need to discuss if we want regular calls or other face-to-face
>       meetings
>  * perform a survey of existing boot-time reduction techniques, and see where they are
>     in the pipeline of upstreaming or deployment in actual products
>  * finally (for this list), brainstorm what activities the SIG should do, and how we can
>     collaborate on those.  I've started a list at: https://elinux.org/Boot_Time_Project_Ideas
>     that you can look at and comment on (either on this list, or on the wiki).
>
> I'll be busy with business travel and Sony work next week, but I hope I still
> find some time to follow up on this .  I look forward to working with many of you
> reading this, on improving this area of Linux.
>  -- Tim
>
>

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

[Rob Landley]

On 10/26/24 02:36, Saravana Kannan wrote:
> On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.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@driftwood) (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

RE: Boot-time initiative (SIG) thoughts and next steps

[Bird, Tim]

> -----Original Message-----
> From: Saravana Kannan <saravanak@google.com>
> On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.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.

Thanks for your interest.  I would love to have developers from Google, 
and from the Android community, involved.

> 
> > 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.
> >
> > A couple of quick things:
> > There are lots of things to discuss, but here are a few things to get started with...
> >
> > = wiki account =
> > The wiki where we'll be maintaining information about
> > boot time, and about activities of the boot time SIG, is the elinux wiki.
> > The page we'll be focusing on is: https://elinux.org/Boot_Time.
> > If you are interested in helping update and maintain the information there
> > (which I hope almost everyone is), then please make sure you have a user
> > account on the wiki.
> > If you don't have one, please go here:
> > https://elinux.org/Special:RequestAccount
> > I have to manually approve accounts in order to fight spambots.  It might
> > take a few days for me to get to your request.  It's very helpful if you
> > put a comment in one of the request fields about this being related to
> > the boot-time initiative or SIG, so I can distinguish your request from
> > spam requests.
> 
> Can we instead keep this all a part of the kernel docs instead of the
> wiki? Couple of reasons for that:

Ideally, we would put some material in the wiki, and also
produce a document - some kind of "boot-time tuning guide" that can
live in the kernel tree.    Some of the material that I think we will
maintain will refer to boot sequences and operations outside the
kernel (such as the bootloader or user-space), so the scope of 
the material to document is not just limited to the kernel.
Also, there will be a lot of material that will be system-specific.
Historically, the kernel has avoided documenting things that are
specific to an individual platform.
Finally, a lot of this information will be ad hoc, which also doesn't
lend itself to upstreaming.

See my response to your individual points below.

> - Since the instructions can be kernel version specific (as things
> change), it makes sense to have the document synced with the kernel.

That's a good point.  The current material suffers from not being synced
very well with kernel versions.  That is, there is a lot of obsolete material.
My own experience is that kernel documentation also has a bit of an issue
with being kept up-to-date, but it's not as bad as wikis often get. 

It would be good to have some plans and possibly mechanisms to address
the eventual obsolescence of the material.

> - It's one less account to maintain and less chores for you.
The cost per developer is one-time, which shouldn't be too bad
for individual developers.  I already have the role of elinux administrator,
and so I have to approve accounts anyway.  In either case
(contributing to a wiki or contributing upstream), there is going to
be some overhead for reviewing the material.

> - One less business approval to get in terms of contributing to
> external sources.
This is an interesting point.  Does Google have rules regarding contributing
to wikis?  That is actually related to my plans to use automation to collect
boot-time data.  My plan is to have tests that automatically send data
to a central collection server (with data that is put into a shared, public database).
I realize there will be some companies who won't want to share certain
details of their in-development platforms.  When I publish the first 
script that does that (probably this week or next), we should discuss the
ramifications of developers needing company consent for this.

> - Less chance of bit rot. As people make changes, the docs are right
> there to go fix.
You are right that bit rot is a significant risk with wikis, because there are
no mechanisms to automatically update or remove obsolete material.
I have some plans to fix that with some test instrumentation and upstream
wiki processes that can automatically detect changes to published data,
and can recommend review of material, or flag it as obsolete.

My own experience is that it is significantly easier to change
something on a wiki, than it is to change upstream kernel documentation.
One requires just changing text using a web form, and the other requires
an upstream-compatible e-mail based submit/review/approve/release cycle.

I'm interested to learn more about the barriers that developers at Google (or other
companies) might face in making contributions to a wiki.  Can you describe
those obstacles in more detail?

Thanks,
 -- Tim

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

[Saravana Kannan]

On Sun, Oct 27, 2024 at 6:30 PM Bird, Tim <Tim.Bird@sony.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Saravana Kannan <saravanak@google.com>
> > On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.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.
>
> Thanks for your interest.  I would love to have developers from Google,
> and from the Android community, involved.
>
> >
> > > 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.
> > >
> > > A couple of quick things:
> > > There are lots of things to discuss, but here are a few things to get started with...
> > >
> > > = wiki account =
> > > The wiki where we'll be maintaining information about
> > > boot time, and about activities of the boot time SIG, is the elinux wiki.
> > > The page we'll be focusing on is: https://elinux.org/Boot_Time.
> > > If you are interested in helping update and maintain the information there
> > > (which I hope almost everyone is), then please make sure you have a user
> > > account on the wiki.
> > > If you don't have one, please go here:
> > > https://elinux.org/Special:RequestAccount
> > > I have to manually approve accounts in order to fight spambots.  It might
> > > take a few days for me to get to your request.  It's very helpful if you
> > > put a comment in one of the request fields about this being related to
> > > the boot-time initiative or SIG, so I can distinguish your request from
> > > spam requests.
> >
> > Can we instead keep this all a part of the kernel docs instead of the
> > wiki? Couple of reasons for that:
>
> Ideally, we would put some material in the wiki, and also
> produce a document - some kind of "boot-time tuning guide" that can
> live in the kernel tree.

This is the part I care most about being in the kernel docs. Eg: what
configs to use. What commandline params to set. Dos and Don'ts for the
drivers, etc. So, good to see that is an acceptable option.

> Some of the material that I think we will
> maintain will refer to boot sequences and operations outside the
> kernel (such as the bootloader or user-space), so the scope of
> the material to document is not just limited to the kernel.

Makes sense.

> Also, there will be a lot of material that will be system-specific.
> Historically, the kernel has avoided documenting things that are
> specific to an individual platform.

A lot of kernel params are arch specific and we still document them in
the kernel. So I don't there's some leeway. But yeah, doesn't make
sense to document stuff like "improve RPi 4 boot time" kinds of stuff
in the kernel. But not sure that makes sense for the elinux.org wiki
either. But we can figure this out as we go.

> Finally, a lot of this information will be ad hoc, which also doesn't
> lend itself to upstreaming.

At least for the kernel params and configs, I don't think it's that
adhoc. The rest, I don't have an opinion.

> See my response to your individual points below.
>
> > - Since the instructions can be kernel version specific (as things
> > change), it makes sense to have the document synced with the kernel.
>
> That's a good point.  The current material suffers from not being synced
> very well with kernel versions.  That is, there is a lot of obsolete material.
> My own experience is that kernel documentation also has a bit of an issue
> with being kept up-to-date, but it's not as bad as wikis often get.
>
> It would be good to have some plans and possibly mechanisms to address
> the eventual obsolescence of the material.
>
> > - It's one less account to maintain and less chores for you.
> The cost per developer is one-time, which shouldn't be too bad
> for individual developers.  I already have the role of elinux administrator,
> and so I have to approve accounts anyway.  In either case
> (contributing to a wiki or contributing upstream), there is going to
> be some overhead for reviewing the material.
>
> > - One less business approval to get in terms of contributing to
> > external sources.
> This is an interesting point.  Does Google have rules regarding contributing
> to wikis?

In all the companies I've worked at, there's always been some level of
sanity check about external contributions to make sure you aren't
accidentally/intentionally signing up the company for something the
company doesn't agree with.

The point is that I don't know what Google's position is wrt
elinux.org and I need to find it out and/or go through any paperwork
that might be necessary to get approval. All that adds a lot of
inertia, at least for me. I know we are okay contributing to LMKL, so
that makes kernel docs a frictionless process from an approval
perspective. And with the other points in mind about bit rot and
keeping things in sync with kernel, I'd prefer the kernel parts of it
being in the kernel docs.

> That is actually related to my plans to use automation to collect
> boot-time data.  My plan is to have tests that automatically send data
> to a central collection server (with data that is put into a shared, public database).
> I realize there will be some companies who won't want to share certain
> details of their in-development platforms.  When I publish the first
> script that does that (probably this week or next), we should discuss the
> ramifications of developers needing company consent for this.

My comment wasn't about this part at all. I don't think boot timing
needs to be run on any unreleased device. There are plenty of released
devices to test with. And we are actively adding Pixel 6 support to
upstream.

-Saravana

> > - Less chance of bit rot. As people make changes, the docs are right
> > there to go fix.
> You are right that bit rot is a significant risk with wikis, because there are
> no mechanisms to automatically update or remove obsolete material.
> I have some plans to fix that with some test instrumentation and upstream
> wiki processes that can automatically detect changes to published data,
> and can recommend review of material, or flag it as obsolete.
>
> My own experience is that it is significantly easier to change
> something on a wiki, than it is to change upstream kernel documentation.
> One requires just changing text using a web form, and the other requires
> an upstream-compatible e-mail based submit/review/approve/release cycle.
>
> I'm interested to learn more about the barriers that developers at Google (or other
> companies) might face in making contributions to a wiki.  Can you describe
> those obstacles in more detail?
>
> Thanks,
>  -- Tim
>
>
>

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

[Brian Masney]

On Mon, Oct 28, 2024 at 03:33:29PM -0700, Saravana Kannan wrote:
> On Sun, Oct 27, 2024 at 6:30 PM Bird, Tim <Tim.Bird@sony.com> wrote:
> > > On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.com> wrote:
> > > > = wiki account =
> > > > The wiki where we'll be maintaining information about
> > > > boot time, and about activities of the boot time SIG, is the elinux wiki.
> > > > The page we'll be focusing on is: https://elinux.org/Boot_Time.
> > > > If you are interested in helping update and maintain the information there
> > > > (which I hope almost everyone is), then please make sure you have a user
> > > > account on the wiki.
> > > > If you don't have one, please go here:
> > > > https://elinux.org/Special:RequestAccount
> > > > I have to manually approve accounts in order to fight spambots.  It might
> > > > take a few days for me to get to your request.  It's very helpful if you
> > > > put a comment in one of the request fields about this being related to
> > > > the boot-time initiative or SIG, so I can distinguish your request from
> > > > spam requests.
> > >
> > > Can we instead keep this all a part of the kernel docs instead of the
> > > wiki? Couple of reasons for that:
> >
> > Ideally, we would put some material in the wiki, and also
> > produce a document - some kind of "boot-time tuning guide" that can
> > live in the kernel tree.
> 
> This is the part I care most about being in the kernel docs. Eg: what
> configs to use. What commandline params to set. Dos and Don'ts for the
> drivers, etc. So, good to see that is an acceptable option.

I'm interested to help contribute to a boot speed document, and I
suspect some others at Red Hat are interested as well. Personally,
I would prefer to have a section in the kernel documentation over a
Wiki. Besides arch-specific recommendations, we can also contribute
some boot speed improvement techniques that we've done that are
specific to RT.

In addition to the recommended configs, I think it would also be
beneficial to list some upstream patches that improve boot speed along
with the kernel version it was introduced in.

Brian

RE: Boot-time initiative (SIG) thoughts and next steps

[Bird, Tim]

> -----Original Message-----
> From: Brian Masney <bmasney@redhat.com>
> Sent: Tuesday, November 5, 2024 5:10 PM
> To: Saravana Kannan <saravanak@google.com>
> Cc: Bird, Tim <Tim.Bird@sony.com>; linux-embedded@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Boot-time initiative (SIG) thoughts and next steps
> 
> On Mon, Oct 28, 2024 at 03: 33: 29PM -0700, Saravana Kannan wrote: > On Sun, Oct 27, 2024 at 6: 30 PM Bird, Tim
> <Tim. Bird@ sony. com> wrote: > > > On Fri, Oct 25, 2024 at 11: 18 AM Bird, Tim <Tim. Bird@ sony. com> wrote: >
> 
> On Mon, Oct 28, 2024 at 03:33:29PM -0700, Saravana Kannan wrote:
> > On Sun, Oct 27, 2024 at 6:30 PM Bird, Tim <Tim.Bird@sony.com> wrote:
> > > > On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.com> wrote:
> > > > > = wiki account =
> > > > > The wiki where we'll be maintaining information about
> > > > > boot time, and about activities of the boot time SIG, is the elinux wiki.
> > > > > The page we'll be focusing on is: https://elinux.org/Boot_Time.
> > > > > If you are interested in helping update and maintain the information there
> > > > > (which I hope almost everyone is), then please make sure you have a user
> > > > > account on the wiki.
> > > > > If you don't have one, please go here:
> > > > > https://elinux.org/Special:RequestAccount
> > > > > I have to manually approve accounts in order to fight spambots.  It might
> > > > > take a few days for me to get to your request.  It's very helpful if you
> > > > > put a comment in one of the request fields about this being related to
> > > > > the boot-time initiative or SIG, so I can distinguish your request from
> > > > > spam requests.
> > > >
> > > > Can we instead keep this all a part of the kernel docs instead of the
> > > > wiki? Couple of reasons for that:
> > >
> > > Ideally, we would put some material in the wiki, and also
> > > produce a document - some kind of "boot-time tuning guide" that can
> > > live in the kernel tree.
> >
> > This is the part I care most about being in the kernel docs. Eg: what
> > configs to use. What commandline params to set. Dos and Don'ts for the
> > drivers, etc. So, good to see that is an acceptable option.
> 
> I'm interested to help contribute to a boot speed document, and I
> suspect some others at Red Hat are interested as well. Personally,
> I would prefer to have a section in the kernel documentation over a
> Wiki
OK - that's at least two votes for an upstream kernel doc.

I think it would be good to have a boot time tuning guide upstream.
I hope to augment that with a tool that will check for various
items or conditions on a machine, and give a list of recommendations.
This could go along with the tuning guide.

However, I would still plan to collect some information on the wiki
that I don't think will be upstreamable.  For example, see this page:
https://elinux.org/Disable_Console

The first few items on that page could be sentences in a kernel tuning
guide, but the data from actual uses I don't think belongs there, as
it will quickly bitrot.  (Indeed the information on that page has already
bitrotted.)

I think it would be useful to gather this results information on a wiki, but its
possible that if reports are sent by e-mail, just a few lore links would
suffice.

> Besides arch-specific recommendations, we can also contribute
> some boot speed improvement techniques that we've done that are
> specific to RT.
That would be great.
 
> In addition to the recommended configs, I think it would also be
> beneficial to list some upstream patches that improve boot speed along
> with the kernel version it was introduced in.
I think this would be good also.

We should discuss what a kernel boot-time tuning guide should look like
and how it should be organized.  Starting this may be one of the first
things the SIG does.  The other one may be a data-gathering tool that
I've been working on, that (of all things) automatically populates a wiki
with boot time data.  I will explain my intentions when I post the script
(likely tomorrow).
 -- Tim

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

[Saravana Kannan]

On Tue, Nov 5, 2024 at 4:45 PM Bird, Tim <Tim.Bird@sony.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Brian Masney <bmasney@redhat.com>
> > Sent: Tuesday, November 5, 2024 5:10 PM
> > To: Saravana Kannan <saravanak@google.com>
> > Cc: Bird, Tim <Tim.Bird@sony.com>; linux-embedded@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: Boot-time initiative (SIG) thoughts and next steps
> >
> > On Mon, Oct 28, 2024 at 03: 33: 29PM -0700, Saravana Kannan wrote: > On Sun, Oct 27, 2024 at 6: 30 PM Bird, Tim
> > <Tim. Bird@ sony. com> wrote: > > > On Fri, Oct 25, 2024 at 11: 18 AM Bird, Tim <Tim. Bird@ sony. com> wrote: >
> >
> > On Mon, Oct 28, 2024 at 03:33:29PM -0700, Saravana Kannan wrote:
> > > On Sun, Oct 27, 2024 at 6:30 PM Bird, Tim <Tim.Bird@sony.com> wrote:
> > > > > On Fri, Oct 25, 2024 at 11:18 AM Bird, Tim <Tim.Bird@sony.com> wrote:
> > > > > > = wiki account =
> > > > > > The wiki where we'll be maintaining information about
> > > > > > boot time, and about activities of the boot time SIG, is the elinux wiki.
> > > > > > The page we'll be focusing on is: https://elinux.org/Boot_Time.
> > > > > > If you are interested in helping update and maintain the information there
> > > > > > (which I hope almost everyone is), then please make sure you have a user
> > > > > > account on the wiki.
> > > > > > If you don't have one, please go here:
> > > > > > https://elinux.org/Special:RequestAccount
> > > > > > I have to manually approve accounts in order to fight spambots.  It might
> > > > > > take a few days for me to get to your request.  It's very helpful if you
> > > > > > put a comment in one of the request fields about this being related to
> > > > > > the boot-time initiative or SIG, so I can distinguish your request from
> > > > > > spam requests.
> > > > >
> > > > > Can we instead keep this all a part of the kernel docs instead of the
> > > > > wiki? Couple of reasons for that:
> > > >
> > > > Ideally, we would put some material in the wiki, and also
> > > > produce a document - some kind of "boot-time tuning guide" that can
> > > > live in the kernel tree.
> > >
> > > This is the part I care most about being in the kernel docs. Eg: what
> > > configs to use. What commandline params to set. Dos and Don'ts for the
> > > drivers, etc. So, good to see that is an acceptable option.
> >
> > I'm interested to help contribute to a boot speed document, and I
> > suspect some others at Red Hat are interested as well. Personally,
> > I would prefer to have a section in the kernel documentation over a
> > Wiki
> OK - that's at least two votes for an upstream kernel doc.
>
> I think it would be good to have a boot time tuning guide upstream.
> I hope to augment that with a tool that will check for various
> items or conditions on a machine, and give a list of recommendations.
> This could go along with the tuning guide.
>
> However, I would still plan to collect some information on the wiki
> that I don't think will be upstreamable.  For example, see this page:
> https://elinux.org/Disable_Console
>
> The first few items on that page could be sentences in a kernel tuning
> guide, but the data from actual uses I don't think belongs there, as
> it will quickly bitrot.  (Indeed the information on that page has already
> bitrotted.)
>
> I think it would be useful to gather this results information on a wiki, but its
> possible that if reports are sent by e-mail, just a few lore links would
> suffice.
>
> > Besides arch-specific recommendations, we can also contribute
> > some boot speed improvement techniques that we've done that are
> > specific to RT.
> That would be great.
>
> > In addition to the recommended configs, I think it would also be
> > beneficial to list some upstream patches that improve boot speed along
> > with the kernel version it was introduced in.
> I think this would be good also.
>
> We should discuss what a kernel boot-time tuning guide should look like
> and how it should be organized.  Starting this may be one of the first
> things the SIG does.

I wrote something like this for the Android ecosystem
https://source.android.com/docs/core/architecture/kernel/boot-time-opt

So, I'm happy to add something like this to the kernel doc if we have
some consensus on having a kernel doc.

-Saravana

> The other one may be a data-gathering tool that
> I've been working on, that (of all things) automatically populates a wiki
> with boot time data.  I will explain my intentions when I post the script
> (likely tomorrow).
>  -- Tim
>

RE: Boot-time initiative (SIG) thoughts and next steps

[Bird, Tim]

> -----Original Message-----
> From: Saravana Kannan <saravanak@google.com>
> On Tue, Nov 5, 2024 at 4:45 PM Bird, Tim <Tim.Bird@sony.com> wrote:
[snip]

> > We should discuss what a kernel boot-time tuning guide should look like
> > and how it should be organized.  Starting this may be one of the first
> > things the SIG does.
> 
> I wrote something like this for the Android ecosystem
> https://source.android.com/docs/core/architecture/kernel/boot-time-opt

I just took a look at this and it looks like a very handy document.
I think having something like this in the upstream kernel doc would
be great.

> So, I'm happy to add something like this to the kernel doc if we have
> some consensus on having a kernel doc.

I don't hear any objections.  I guess we'll get some feedback when we
post some patches to the linux-doc mailing list.

I would say go for it, and copy this list so we can discuss the planned
document format (and content, of course).

A lot of the information in the android doc would apply to the kernel doc.
 -- Tim