On Thu, Mar 6, 2014 at 12:13 AM, Don Zickus <dzickus(a)redhat.com> wrote:
On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus <dzickus(a)redhat.com> wrote:
> > On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
> > For example, lets start with 100MB package requirement for the kernel (and
> > say 2 GB for userspace). This way the kernel team can implement
> > reasonable changes and monitor proper usage (because things grow over
> > time).
> > If later on you realize 100 MB is not competitive enough, come back and
> > chop it down to say 50 MB and let the kernel team figure it out.
> > But please do not come in here with a 'every MB counts' approach. It
> > not very sustainable for future growth nor really easy to implement from
> > an engineering approach.
> > Is that acceptable? The kernel team can start with a hard limit of 100MB
> > package requirement (or something reasonably less)? Let's work off budget
> > requirements please.
> This is a fair point. To be honest, I've ignored the "every MB
> counts" aspect entirely for now. I've instead been focusing on
> required functionality, because that's likely going to be the main
> driver of what the resulting size will be.
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.
Of course. :-)
> FWIW, the existing kernel package installed today (a debug kernel
> even) is ~142 MB. 123MB of that is the /lib/modules content. ~6MB of
> that is vmlinuz. The remaining 13MB is the initramfs, which is
> actually something that composes on the system during install and not
> something we can shrink from a packaging standpoint.
It also helps with monitoring. 3-4 years from now after all the chopping,
these pacakges bloat right back up and everyone forgets why we chopped in
the first place. Hard requirements help keep everything in check and
forces people to request more space which the cloud team can evaluate
properly and still control their enviroment.
Well, if we can remember why we put up a fixed size requirement, why
can't we remember why we did the chopping? ;) Anyway, I think it's
fair to define a "kernel-core should be smaller than X MB" requirement
but I don't think it's fair to say Y MB because I like the number Y. I
also don't like that we might throw out e.g. NFS just because we're
1MB over the limit.
But if it helps the kernel team to have a fixed number, someone tell
me what we roughly save by throwing out the stuff we discussed and we
can discuss what number would long-termish make sense, I guess. Also,
I'm not sure whether we should measure the extracted files, the
compressed RPM or both.