Re: Modular Kernel Packaging for Cloud

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 06, 2014 at 10:04:56AM -0500, Don Zickus wrote:
> On Thu, Mar 06, 2014 at 08:38:44AM +0900, Sandro "red" Mathys wrote:
> > On Thu, Mar 6, 2014 at 1:45 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> > > On Wed, 05 Mar 2014 17:37:42 +0100
> > > Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
> > >> in general you need to multiply the wasted space for each instance
> > 
> > Exactly, you usually have hundreds or even thousands of instances
> > running. Sure, "every MB counts" isn't to be taken literal here, maybe
> > I should rather have said "every 10 MB count".
> > 
> > > At least for my uses, the amount of non persistent disk space isn't a
> > > big deal. If I need disk space, I would attach a persistent volume...
> > 
> > Figure you get your additional persistent volumes for free somehow, so
> > all those Amazon AWS, HP Cloud, Rackspace, etc. users envy you. And
> > those admins that need to buy physical disks to put into their private
> > clouds, too.
> > 
> > Also, more data equals more network traffic and more time - both
> > things that matter in terms of costs, at least in public clouds.
> 
> Sure, but what if the trade-off in size comes with a cost in speed?  Is
> cloud ok with the kernel taking twice as long to boot?  Or maybe running
> slower?  Or maybe crashing more often (because we removed safety checks?).
> 
> I mean if Josh wanted to he could make everything modular and have a
> really small kernel footprint (like 40MB or so) running in 50MB of memory
> (I have done this with kdump).  But it costs you speed in loading modules
> (as opposed to built into the kernel).  You may lose other optional
> optimizations that help speed things up.
> 
> Other SIGs made not like it, but again it depends on how you frame your
> environment.  Maybe cloud really needs its own kernel.  We don't know.

To touch on this a bit, if splitting the kernel up becomes unwieldy we
could possibly just build kernel-cloud as another flavour in kernel.spec
(similar to PAE, debug, etc).  I'm not much of a fan of this though, as
it can lead to a very divergent vmlinux over time.

If it's _necessary_, that's one thing.  I've yet to really see any data
backing up necessity on any of this at all though.  Right now it seems
to be sitting in the "nice to have" category.

Perhaps someone from the cloud team could look at existing images from
other distros and figure out kernel sizes there, and how it plays into
usage and cost in those environments?

josh
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux