Re: armel/marvell kernel size
Hi Ben and others.
On Fri, Mar 23, 2018 at 10:50 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Fri, 2018-03-23 at 18:15 -0300, Rogério Brito wrote:
> [...]
> > HOLY MOLY! THIS THING IS SLOW on my Core 2 Duo notebook... Granted, I only
> > have 4 GB of RAM, but the amount of modules that it compiles is
> > HUGE... Quite different from a "regular" kernel that I used to compile...
>
> Don't you have access to something faster you can work on?
Unfortunately, not at this moment. My desktop (a Phenon II X4) was
fried during a power outage. :-(
> You should be able to save time and disk space by disabling debug info,
> as that won't make any difference to the eventual kernel size. You can
> do that by adding "debug-info: false" to the [build] section in
> debian/config/armel/defines.
I did that and it seems to help a bit.
> ccache can also be useful, though it doesn't help if you change a config symbol that affects some widely
> used header file.
Yes, I was already using ccache and I find it invaluable.
> > I will see if all the modules make sense for an embedded system like this
> > and I will send a list of options for opinions by others...
> [...]
>
> As I see it, the point of installing Debian on little NAS boxes is to
> break out of the restrictions of an embedded system. We try to
> provide, so far as possible, the same features across all
> architectures.
It sure makes sense to provide a lot more than some kernels, but I am
curious about some features that end up as modules like some
framebuffer like the following:
(...)
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
CONFIG_FB_S3=m
CONFIG_FB_S3_DDC=y
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
CONFIG_FB_3DFX=m
# CONFIG_FB_3DFX_ACCEL is not set
CONFIG_FB_3DFX_I2C=y
# CONFIG_FB_VOODOO1 is not set
(...)
Is there any reason why, say, a driver for an S3 card is enabled while
not for a Matrox? Are there real users for those? I know that, as
modules, they don't make the kernel bigger, but they sit there on
disk, doing nothing (right?).
Similarly for wifi cards like those Intel ones like iwlwifi (which is
the one that I have in this Core 2 Duo here)...
OK, now to the real meat of my message. Regarding shrinking the
kernel image, I was able to tweak things slightly (drop from 101% down
to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the
deadline IO scheduler instead of the CFQ and making as modules the
ones that you suggested in the original message... Is that acceptable?
If so, then I will test them on my Kurobox Pro and report what works
and what breaks. I just wanted to get things smaller by tackling some
lower hanging fruit...
Another point: from what I saw in the Debian scripts, not all
armel/marvell systems are limited to 2MB (in particular, the Kurobox
Pro with which I am most concerned still has 630KB of room)... In the
very worst case (of course, this is not what we want), if the kernel
actually gets much bigger in time for the buster release, we could
selectively drop some systems (like what was done with the DNS323)
instead of dropping an entire arch... I even think that a new,
smaller, alternative flavor of the kernel is possible to provide to
support those systems that are limited to 2MB of kernel image... (I
can commit to support that, if my initial ideas work and people accept
them).
Of course, if we could make some real magic and make our kernels much,
much smaller to support back the DNS323, that would be amazing... :-)
I guess that I will look into those LTO patches in the future...
OK, I am sending this to see if those ideas make sense, to offer my
help and, of course, to get some feedback.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Reply to: