On Wed, Oct 30, 2013 at 10:07:46AM -0400, Josh Boyer wrote:
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team has heard in the past that the Cloud group would like
to see something of a more minimal kernel for usage in cloud images.
We'd like to hear the requirements for what this smaller image would
need to cover.
Right now, a default x86_64 kernel package on f20 is ~134MB installed.
Most of that is device drivers installed in /lib/modules/`uname -r`/.
The vmlinux binary is about 5MB and the initramfs (which is created
at install time and can actually vary quite widely depending on
various things) is about 11MB. Drivers can be trimmed to a degree,
but please keep in mind that the kernel is already relatively small
for the functionality it provides. For example, it is not much bigger
than glibc-common (119MB).
So, some caveats to keep in mind while you're thinking about this:
1) We're mostly talking about packaging here, not building a separate
cloud kernel package or vmlinux. The kernel team really wants to have
a single vmlinux across the 3 products if at all possible. We can't
scale to much else.
2) What usecases is the cloud image going to cover? E.g. is it just
virtio stuff, or will it also fit PCI passthru (which then requires
drivers for those PCI devices)?
FWIW, OpenStack cloud now supports use of PCI passthrough for guests,
so looking at the most general cloud case, we can't remove all the
non-virtio stuff. Most common PCI passthrough usage will likely be
for SRIOV NIC devices, with others more niche use-cases.
3) What are the common provisioning requirements that are driving
size reduction? (See comment about glibc-common. I would think
change is needed in multiple packages, not just the kernel.)
4) Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
Does anyone have an accurate report on where physical space in the
current cloud image goes to ? Just doing a 'du' on the cloud image
is only giving logical disk space, which doesn't correspond directly
to physical image space, due to differing compression ratios for
different types of content.