From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mackerras <paulus@samba.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Fr?d?ric Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [GIT PULL, v2] perf changes
Date: Fri, 28 May 2010 09:00:26 +0200 [thread overview]
Message-ID: <20100528070026.GA31058@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1005271533010.11382@i5.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 25 May 2010, Ingo Molnar wrote:
> >
> > 75 files changed, 1847 insertions(+), 3147 deletions(-)
>
> I was excited by this ("A code _reduction_! Will wonders never cease?"), but
> it turns out that all of the reduction was due to removing some unused
> utility functions from the user-level tools.
Simple things first and maybe it turns into a habit!
> The actual kernel still grew:
>
> 32 files changed, 1327 insertions(+), 964 deletions(-)
>
> oh well. Merged anyway.
Hey, while i have to admit to being a member of the infinitely large group of
kernel developers working hard to ensure that the kernel's size follows
Moore's Law - this time i beg to differ, as we _did_ manage to shrink the
kernel! ;-)
Here's the before/after vmlinux comparison:
(x86 defconfig, 64-bit): vmlinux:
text data bss dec hex filename
.......................................................
cad719d (before): 8441843 1281100 983876 10706819 a35f83 vmlinux
c5617b2 ( after): 8417488 1277724 983876 10679088 a2f330 vmlinux
.......................................................
-24.35K -3.37K
-0.28% -0.26%
Ob'Suggestion: we could help debloating efforts by officially declaring to
take provably-debloating patches up to -rc4? (with a vmlinux comparison
mandated in the changelog or such)
Debloating patches tend to reduce complexity, and hence are more
regression-resistent. (They are also rare, so it's not like we would be
risking a flood of patches.)
That would be a clever way to redirect the creative energies of kernel
developers who are otherwise bored by -rc1's legendary stability and always
try to sneak further features upstream post -rc1.
Such a policy would mean that while the merge window for bloating patches is a
strict ~1.5 weeks, the merge window for debloating patches would be a generous
~1.5 months.
Maybe such a mild hint would help propagate the idea some more.
Dunno - just an idea,
Ingo
prev parent reply other threads:[~2010-05-28 7:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 19:25 [GIT PULL] perf changes Ingo Molnar
2010-05-25 0:22 ` Paul Mackerras
2010-05-25 13:52 ` [GIT PULL, v2] " Ingo Molnar
2010-05-27 22:34 ` Linus Torvalds
2010-05-27 23:08 ` Arnaldo Carvalho de Melo
2010-05-28 0:32 ` Steven Rostedt
2010-05-28 0:43 ` Arnaldo Carvalho de Melo
2010-05-28 7:00 ` Ingo Molnar [this message]
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=20100528070026.GA31058@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.