Re: armel/marvell kernel size
Dear Roger, Ben and others.
On Sun, Apr 1, 2018 at 10:25 AM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote:
>> There's an upstream change in cfg80211 that enables direct-loading of
>> wireless rules, which requires public key crypto in the kernel. There
>> doesn't appear to be any option to disable that mode, even though we
>> don't need it because crda still works. Maybe you could disable
>> wireless networking completely?
>
> I finally settled a solution, by introducing a new armel flavour:
> mini, which doesn't support wireless.
> There're still some users that need wireless, so I didn't remove
> wireless from armel/marvell directly.
I think that we should still strive to pretend that there's a hard 2MB
limit and to shave some parts that can before we start creating a new
flavor of the kernel... This would force us to think harder about
disabling things in general... In general, I think that we can discuss
a little bit more about what to include/exclude from such smaller
kernels and which flavors to have.
In other words, I agree with your end goal, but, perhaps, we can plan
this a bit more...
> So here I propose to have:
> - marvell to support all generic feature and being able to tuned for
> performance.
> - mini without wireless and being minimum.
>
> Patches are all enclosed, and pushed to salsa rosh/armel_mini branch.
> - 0001: Bring back qnap support by a new armel flavour: mini (Disable
> WIRELESS, WLAN, etc)
> - 0002: [armel/mini] Add flavour mini to installer
> - 0003: [armel/mini] Further change a few features as module (I2C,
> I2C_CHARDEV, I2C_MV64XXX,
> MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION)
I would make your commits more granular, with one semantic change per
commit, to revert and or/bisect in an easier fashion...
> I tested on stretch by cross compiling, here's generated kernel size.
> - original 4.16~rc6-1~exp2: 2142704
> - After patch 0001: 2017088
> - After patch 0002: 2017088
> - After patch 0003: 1985896
>
> Here's my testing result regarding those features that changed to module:
> (tested under stretch)
I'm doing my tests under testing (buster). See more below.
>> Some options that could possibly be changed from y to m:
>>
>> - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C
>> drivers to the initramfs if needed, but I'm not certain.
>
> No, i2c nor i2c_mv64xxx will be loaded. But my armel box seems fine
> without them.
> Of course, manually "modprobe i2c_mv64xxx" will load the module well.
While I have compiled a kernel with those options all enabled as
modules, I have not yet had time to boot it (in fact, I created a lot
of kernels that I want to test all in one sitting), but I agree with
the principle of your testing, Roger and, in the worst case, we can
instruct the users to add those to /etc/modules if they absolutely
need them.
I would not qualify this as a change for only a new kernel flavor,
that is, I would make this change in general...
>> - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break
>> some systems unless initramfs-tools is updated to include and load the
>> cmdlinepart module.
>>
>> - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that
>> should load the system clock from the first RTC if its driver is a
>> module.
>>
>> - SPI_ORION. initramfs-tools should include this in the initramfs if
>> needed, but I'm not certain.
>
> Yes, above 3 modules are loaded without glitch.
All those are generic material that I would also make generic instead
of only particular to a given flavor.
>> Some options that could possibly be disabled:
>>
>> - AUDIT. This is quite a niche feature.
>
> I tried, but couldn't. Maybe next time.
You probably missed this, but I said in a previous message that AUDIT
is automatically selected by AppArmor. In other words, you can have
only the following options:
* with AppArmor (and AUDIT)
* without AppArmor (but with AUDIT)
* without AppArmor and without AUDIT
>From my perception, Ben was mildly opposed to having AppArmor disabled
by default and wanted to have the kernel as close as possible to other
arches...
For that reason, I would still keep AppArmor in the big, reference
armel kernel, but opt to create a flavor without AppArmor (and without
AUDIT) for the people that may want to use a small kernel or for those
(like me) that never use AppArmor (or that have not yet seen the light
with the benefits of a MAC module).
Besides your proposed changes, I have some other things in mind that I
have in patches here and that I will send after I get access to the
notebook where I compiled things:
1 - I would change from the CFQ to the DEADLINE governors *in the
general kernel*, as it makes the kernel slightly smaller, but, in my
experience, working as well as a CFQ in practice.
2 - Another excellent option is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
suggested by Leigh Brown (taken from
https://lists.debian.org/debian-arm/2018/03/msg00035.html). The amount
of reduction in size with my system was surprising (much smaller than
what I expected by changing the governors or when changing some
options from y to m).
Since I mentioned my environment, please, keep in mind that:
* The compiler that I am using for everything here is the one from
testing (buster) and it is GCC 7 at the moment (have not tried using
GCC 8 to see the differences yet)
* I am optimizing things for size (which, in some cases, may be
beneficial for machines with small L1/L2 caches too)
I would change the default from optimizing for size (-Os) to
optimizing for speed (-O2) only after all the low-hanging fruit with
kernel options were decided and, then, I would think hard if it makes
sense to have -O2 with a small kernel or with the full blown kernel.
Another option suggested by Leigh in that message was that
+# CONFIG_CRC32_SLICEBY8 is not set
+CONFIG_CRC32_SLICEBY4=y
can make the kernel smaller and, if I remember the descriptions of the
options, it made sense that those would reduce the size of the kernel
both compressed and uncompressed... This would be something that I
would suggest for a general kernel also...
I am not sure about disabling the VT option as Leight suggested... I
don't think that I have ever used one of those...
I think that we can compile out YAMA from the general kernel, since, I
would believe that it is less frequently used (we can upload a kernel
with this disabled to experimental or to a personal space and ask
people to experiment it) and it is disabled by default in Debian's
kernel...
For a -mini kernel, some of the first things that come to my mind
would be to disable:
* some hardware framebuffers like the S3 and similar ones, even if
build as modules.
* your suggestion of disabling wifi drivers and the wifi subsystem
* disabling some less commonly used local or distributed filesystems
(some of which are large or demand many other options to be enabled)
or that have better functionality in userspace (like the NTFS read
support in the kernel being disabled and recommend ntfs3g to the
users), but keeping popular ones and services like ext2/3/4, XFS, NFS,
Mounting CIFS is probably a good idea, but having OCFS or other
systems, I don't know.
* disabling some partition types for the smaller kernels, after
benchmarking them...
* disabling joystick/video/audio capture etc drivers.
* disabling yama/apparmor/audit.
* disabling unused kernel algorithms or those that aren't pulled in by
any modules (I remember at least one that said: don't enable this one
unless you have an out-of-tree module that needs it).
Oh, I would *not* disable zswap from the smaller kernel, since I would
plan on going not only with zbud but also with z3fold and test the
stability and performance of the kernel with it, as machines that are
memory-starved can benefit from a higher density of compression...
When introducing a new flavor, I guess that we could make the current
flavor, instead of none, being -standard, a new one called -mini
(similar in spirit to yours) and, potentially, another called -micro
to users of DNS323 (if the -mini flavor does not fit in the 1.5MB
after all these changes)...
Furthermore, with the LTO work on the kernel, I am hopeful that
if/when it gets merged, we can make everything even smaller and be
much happier... :-) OK, I'm excited to have very small kernels despite
the kernel in general growing from version to version with more and
more features being integrated...
Please, let me know your opinions.
I will now go to bed, but I will send my patches as soon as I wake up
and deal with morning stuff. In the end, I intend to enable support
for as many things are available in the mainline (even the DNS323, for
which I don't have the hardware, but since we are with our hands
dirty, let us extend the value of those machines for the users of such
hardware...)
Thanks,
Rogério Brito.
P.S.: Only now I saw that one of your patches already implement the
option that Leigh suggested... But I think that we can use more
modular options both in the "main" kernel and in the smaller flavors.
P.P.S.: Sorry if this message is badly composed, if there are
unfinished sentences or if something doesn't make sense, but I just
wanted to make sure that the thoughts that I have here in my head get
discussed with others and not only confined to myself.
--
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: