Modular Kernel Packaging for Cloud

[Don Zickus]

On Thu, Mar 06, 2014 at 10:33:47AM -0500, Josh Boyer wrote:
> On Thu, Mar 6, 2014 at 9:57 AM, Don Zickus <dzickus at redhat.com> wrote:
> > On Thu, Mar 06, 2014 at 08:16:00AM +0900, Sandro "red" Mathys wrote:
> >> That's the point, we want a reasonably small package while still
> >> providing the required functionality. Not sure how providing a fixed
> >> size number is helping in this. But most of all, I didn't throw in a
> >> number because I have no idea what is reasonably possible. I really
> >> only just said "every MB counts" because the question came up before
> >> (in Josh's old thread) and I hoped I could stop this discussion from
> >> happening again before we have any numbers for this.
> >
> > Ever work in the embedded space?  Every MB counts there too. :-)  This was
> > solved by creating budgets for size and memory requirements.  This helped
> > control bloat, which is going to be your biggest problem with cloud
> > deployment.
> >
> > What concerns me is that you don't know what size your cloud deployment is
> > but expect everyone to just chop chop chop.  How do we know if the kernel
> > is already at the right size?
> >
> > There is s a huge difference between re-architecting the kernel packaging
> > to save 1 or 2 MB (off ~143 MB size currently) vs. re-architecting to save
> > 50 MB.  The former is really a wasted exercise in the bigger picture,
> > wherease the latter (if proven needed) accomplishes something.
> >
> > But again it comes down to understanding your environment.  Understanding
> > your environment revovles around control.  I get the impression you are
> > not sure what size your environment should be.
> >
> > So I was proposing the kernel stay put or maybe create _one_ extras
> > package that gets installed in addition to the bzImage.  But from the
> 
> Right.  When I said I had kernel-core and kernel-drivers, I wasn't
> being theoretical.  I already did the work in the spec file to split
> it into kernel-core and kernel-drivers.  The kernel package becomes a
> metapackage that requires the other two, so that existing installs and
> anaconda don't have to change (assuming I did thinks correctly).
> Cloud can just specify kernel-core in the kickstart or whatever.
> 
> > sound of it, the chopping is really going to get you savings of about
> > ~30MB or so.
> 
> I spent some time yesterday hacking around on an existing VM and just
> removing stuff from /lib/modules/ for an installed kernel.  I was able
> to get it down from 123MB to 58MB by axing entire subsystems that
> clearly didn't apply and running depmod on the results to make sure
> there weren't missing dependencies.  Some stuff had to be added back
> (want virtio_scsi? you need target and libfc), but a lot could be
> removed.  That brings the total to about 81MB for vmlinuz, initramfs,
> and /lib/modules for that particular kernel.

Ok.  That is pretty damn good.  Good job!  Again the question is, is that
enough?

> 
> In those 81MB, I still had all of the main GPU drivers, all of the
> intel and a few other ethernet drivers, ext4, xfs, btrfs, nfs, the
> vast majority of the networking modules (so iptables and netfilter),
> scsi, acpi, block, char, etc.  The major things missing were bluetooth
> and wireless, infiniband, some firewire stuff.  Basically it resulted
> in a system that boots perfectly fine in a VM for a variety of
> different use cases.
> 
> I think that's a reasonable start, and it's a significant reduction.
> Beyond that, we get into much less reduced savings and having to move
> stuff around on a finer level.  For the curious, I uploaded the module
> list here:
> 
> http://jwboyer.fedorapeople.org/pub/modules.small

You might be able to chop sound/ too (I know we could probably go crazy
and chop lots of other things too., just thought sound/ would be a big easy
chop).

Does this approach affect other SIGs too?  Most of the others don't care
about disk and memory space, right?

Cheers,
Don