how to reduce both vmlinuz size and modules?

how to reduce both vmlinuz size and modules?

[Robert P. J. Day]

  currently running latest version of fedora 23, with
4.2.8-200.fc22.x86_64 fedora kernel package, and i'm wondering about
the best way to both reduce the kernel size, and cut down on the
number of modules i'm building, based on what looks like combining a
couple of make targets.

  if i start with the latest git kernel repo, it *looks* like i can
use the /boot/config-4.2.8-200.fc22.x86_64 config file as a starting
point, copy it in as .config, then:

 $ make allmodconfig
 $ make localmodconfig

as i read it (and i could be mistaken), the first make would transform
as many "y" kernel selections to "m" as possible, while the second
would then remove any module config selections that are currently not
loaded.

  am i reading that correctly? is there a simpler way to do this?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

how to reduce both vmlinuz size and modules?

[Valdis.Kletnieks at vt.edu]

On Sat, 26 Dec 2015 10:39:04 -0500, "Robert P. J. Day" said:

>   if i start with the latest git kernel repo, it *looks* like i can
> use the /boot/config-4.2.8-200.fc22.x86_64 config file as a starting
> point, copy it in as .config, then:
>
>  $ make allmodconfig
>  $ make localmodconfig

How much simpler could you make it? :)

The place you're most likely to screw it up is to forget to plug in all
your USB and other widgets at least once before the 'make localmodconfig'
to make sure they get modprobed.

As a practical matter, if 'make allmodconfig' had slightly different semantics,
we could do better.  'allmod' has semantics of 'turn on every possible =m'.
If there were a semantic of 'convert as many existing =y into =m, but *don't*
convert =n into =m', we could do this and it would almost certainly be
faster.

boot distro kernel
(plug in widgets)
make localmodconfig
boot into that kernel
make mostlymodconfig
boot
plug in widgets
make localmodconfig  *again*

The reason it would be faster - a Fedora Rawhide kernel has 2,793 =m, a
'allmodconfig' has 5,162 - but doing a 'localmodconfig' gets it down to
33 on my laptop (though admittedly I've made a lot of device drivers =y
so they're part of vmlinux - but /sys/module tells me there's a max of
133 or so of those).  So after the first 'localmodconfig', you've gotten
rid of probably 75% to 90% of the modules to build, and thus build time.
It's probably faster to do 3 builds like this than an allmod/mostlymod
pair.

Note that if you're *really* concerned about vmlinux size (like embedded
devices), you'll want to make a second pass through all the =y, and see
how many are system features you don't need, but which can't be modular.
Things like SYSV shared memory and IPC, BSD process accounting, and so on...

I wonder if adding a 'mostlymodconfig' to Kconfig would be worthwhile.
Comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151226/28a399b0/attachment.bin 

how to reduce both vmlinuz size and modules?

[Robert P. J. Day]

On Sat, 26 Dec 2015, Valdis.Kletnieks at vt.edu wrote:

> On Sat, 26 Dec 2015 10:39:04 -0500, "Robert P. J. Day" said:
>
> >   if i start with the latest git kernel repo, it *looks* like i
> > can use the /boot/config-4.2.8-200.fc22.x86_64 config file as a
> > starting point, copy it in as .config, then:
> >
> >  $ make allmodconfig
> >  $ make localmodconfig
>
> How much simpler could you make it? :)

  i'm not sure, that's why i asked. :-) i was pretty sure there was no
*single* make target that did what i wanted, i just want to make sure
i understand the semantics of the two targets above.

  as i read it (and, admittedly, i still need to read the code in more
detail), "make allmodconfig" will select as much as it possibly can as
modules so, in the end, i would have a functionally equivalent
bootable system with a smaller kernel, along with a zillion compiled
modules (most of which i don't need).

  the second make target would then leave the definition of the
vmlinux build alone, and simply reduce the module selection to what is
currently loaded. so as long as my understanding of those targets is
correct, that seems to be what i'm after.

> The place you're most likely to screw it up is to forget to plug in
> all your USB and other widgets at least once before the 'make
> localmodconfig' to make sure they get modprobed.

  i know, that's the fear, so i'm plugging in various devices i use
(like my android phone) just to see what modules kick in.

> As a practical matter, if 'make allmodconfig' had slightly different
> semantics, we could do better.  'allmod' has semantics of 'turn on
> every possible =m'. If there were a semantic of 'convert as many
> existing =y into =m, but *don't* convert =n into =m', we could do
> this and it would almost certainly be faster.
>
> boot distro kernel
> (plug in widgets)
> make localmodconfig
> boot into that kernel
> make mostlymodconfig
> boot
> plug in widgets
> make localmodconfig  *again*
>
> The reason it would be faster - a Fedora Rawhide kernel has 2,793
> =m, a 'allmodconfig' has 5,162 - but doing a 'localmodconfig' gets
> it down to 33 on my laptop (though admittedly I've made a lot of
> device drivers =y so they're part of vmlinux - but /sys/module tells
> me there's a max of 133 or so of those).  So after the first
> 'localmodconfig', you've gotten rid of probably 75% to 90% of the
> modules to build, and thus build time. It's probably faster to do 3
> builds like this than an allmod/mostlymod pair.
>
> Note that if you're *really* concerned about vmlinux size (like
> embedded devices), you'll want to make a second pass through all the
> =y, and see how many are system features you don't need, but which
> can't be modular. Things like SYSV shared memory and IPC, BSD
> process accounting, and so on...
>
> I wonder if adding a 'mostlymodconfig' to Kconfig would be
> worthwhile. Comments?

  i think that could be useful unless (as you point out) it can be
emulated easily with a couple other targets. anyway, time to give this
a try.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

how to reduce both vmlinuz size and modules?

[Robert P. J. Day]

On Sat, 26 Dec 2015, Valdis.Kletnieks at vt.edu wrote:

> On Sat, 26 Dec 2015 10:39:04 -0500, "Robert P. J. Day" said:
>
> >   if i start with the latest git kernel repo, it *looks* like i can
> > use the /boot/config-4.2.8-200.fc22.x86_64 config file as a starting
> > point, copy it in as .config, then:
> >
> >  $ make allmodconfig
> >  $ make localmodconfig
>
> How much simpler could you make it? :)
>
> The place you're most likely to screw it up is to forget to plug in
> all your USB and other widgets at least once before the 'make
> localmodconfig' to make sure they get modprobed.
>
> As a practical matter, if 'make allmodconfig' had slightly different
> semantics, we could do better.  'allmod' has semantics of 'turn on
> every possible =m'. If there were a semantic of 'convert as many
> existing =y into =m, but *don't* convert =n into =m', we could do
> this and it would almost certainly be faster.

  yeah, that's definitely what i'm after. i see no immediate way to
fake or emulate that.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================