From: Christoph Lameter <cl@gentwo.org>
To: "Bird, Tim" <Tim.Bird@sonymobile.com>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] RFC: Kernel tinification - kernel config reduction
Date: Thu, 14 Aug 2014 11:03:34 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.11.1408141101070.26361@gentwo.org> (raw)
In-Reply-To: <F5184659D418E34EA12B1903EE5EF5FD0130D4AC5B90@seldmbx02.corpusers.net>
On Wed, 13 Aug 2014, Bird, Tim wrote:
> I propose that we remove or hide a lot of the configuration options related
> to size, and instead focus on size profiles. When someone wants to build a
> minimal Linux system, they don't really want to manually trim down every
> Linux sub-system. The more common development case is that they want
Yes exactly.
> a fully minimal Linux system, except for one or two areas where they want
> some flexibility in features. I propose that we tie most of the options that
> are currently in the kernel for size reasons to a single or a few meta-options:
> e.g. CONFIG_SMALL, CONFIG_TINY, CONFIG_RIDICULOUS. These
> different meta-config options can get better testing, and this will help curb
> the proliferation of size-related config options (and the resulting test
> combination explosion for those individual options.)
I'd be interested to configure minimally sized systems in order to
increase performance. The cache footprint determines performance these
days so a tinyfication project will have performance implications as well
and has the potential to significantly speed up key kernel functionality.
> Optimally it would be nice to have the ability to configure a small system, and
> then "back off" of the tiny config in a particular area (say networking).
> I believe this would yield a much more tractable system for building small
> systems with Linux, than the current situation.
That could be useful also to come up with high performant kernels for
special functionality. Come up with a tiny config and then add config
options to enable only what is needed.
Reminds me of what Gentoo is doing
> I'd like to discuss implementation ideas for this in the hallway track at KS.
>
> Thoughts?
Get a room instead of the hallway?
next prev parent reply other threads:[~2014-08-14 16:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 17:29 Bird, Tim
2014-08-13 18:07 ` Guenter Roeck
2014-08-13 19:53 ` Geert Uytterhoeven
2014-08-13 22:45 ` Guenter Roeck
2014-08-14 0:14 ` Mark Brown
2014-08-14 0:38 ` Guenter Roeck
2014-08-14 15:33 ` Mark Brown
2014-08-14 7:49 ` Geert Uytterhoeven
2014-08-14 16:39 ` Mark Brown
2014-08-14 7:40 ` Geert Uytterhoeven
2014-08-14 8:50 ` Guenter Roeck
2014-08-14 9:02 ` Geert Uytterhoeven
2014-08-15 11:04 ` Guenter Roeck
2014-08-14 19:57 ` Stefan Hengelein
2014-08-13 19:19 ` josh
2014-08-14 16:30 ` Tim Bird
2014-08-14 17:17 ` Josh Triplett
2014-08-14 16:03 ` Christoph Lameter [this message]
2014-08-14 18:54 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.11.1408141101070.26361@gentwo.org \
--to=cl@gentwo.org \
--cc=Tim.Bird@sonymobile.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox