[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120810150157.GA23457@leaf>
Date: Fri, 10 Aug 2012 08:01:57 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Serge Hallyn <serge.hallyn@...onical.com>
Cc: Alex Kelly <alex.page.kelly@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Heiko Carstens <heiko.carstens@...ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Kees Cook <keescook@...omium.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 2/3] fs: Make core dump functionality optional
On Fri, Aug 10, 2012 at 08:23:23AM -0500, Serge Hallyn wrote:
> Quoting Alex Kelly (alex.page.kelly@...il.com):
> > Adds an expert Kconfig option, CONFIG_COREDUMP, which allows disabling of core dump.
> > This saves approximately 2.6k in the compiled kernel, and complements CONFIG_ELF_CORE,
> > which now depends on it.
>
> Is there another reason than the 2.6k to do this? My kernels range
> between 4.8 and 5M, so that's .05% size savings?
A kitchen-sink kernel might take up that much space, but you can build a
minimal embedded kernel that only takes up ~200k, at which point 2.6k
represents a >1% decrease. Add a few more changes like this, and those
decreases start to add up. At this point, no one thing you can chop out
of the kernel will give you a 100k decrease by itself; you need a pile
of changes like this one to do that.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists