Re: armel/marvell kernel size
Dear Rogério,
I'll reply to you later, in a separate email.
Dear kernel folks,
After all kinda tests recently, together with the patch from Leigh
Brown (CC-ed) that disabled VT, finally the armel/marvell can be
reduced under 2MB again, without introducing a new flavour.
So I already pushed the changes to master and sid branch in salsa.
qnap support will be back in next debian kernel release.
Cheers,
Roger
On Tue, Apr 3, 2018 at 2:37 PM, Rogério Brito <rbrito@ime.usp.br> wrote:
> 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: