From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Adrian Bunk <bunk@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Sam Ravnborg <sam@ravnborg.org>,
Alexander Viro <viro@ftp.linux.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches
Date: Tue, 06 May 2008 02:21:31 +0200 [thread overview]
Message-ID: <874p9ccmes.fsf@basil.nowhere.org> (raw)
In-Reply-To: <20080505201906.GA900@elte.hu> (Ingo Molnar's message of "Mon, 5 May 2008 22:19:06 +0200")
Ingo Molnar <mingo@elte.hu> writes:
> But the per patch benefit is arguably extremely low: for example this
> particular patch saves 0.00016% from my particular vmlinux's size.
I don't think the code changes actually with current gcc for integer
code if you change something from global to static (unless it causes
gcc to inline the function, but then it might be well larger if you're
unlucky)
The only file size change you'll see will be from a smaller symbol
table in the vmlinux ELF file, but that is not even loaded at run time
or included into the bzImage (and the kallsyms table has statics too)
So if we follow that "smaller symbol table" is better model
should we make a rule that all globals be 8 characters only? Or perhaps 6? @)
I'm sure that could be easily enforced by some tool...
I could see some advantage from static in future compiler versions
though from better optimization, but it's quite remote.
I agree with your point that it's not effective to spend human time
to generate such patches.
-Andi
next prev parent reply other threads:[~2008-05-06 0:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 18:29 [2.6 patch] make sched_feat_{names,open} static Adrian Bunk
2008-05-05 20:19 ` [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat_{names,open} static) Ingo Molnar
2008-05-05 20:40 ` Randy.Dunlap
2008-05-05 21:51 ` Arjan van de Ven
2008-05-05 23:19 ` david
2008-05-05 23:40 ` Arjan van de Ven
2008-05-05 23:45 ` Theodore Tso
2008-05-06 3:23 ` Arjan van de Ven
2008-05-06 5:48 ` Arjan van de Ven
2008-05-05 20:42 ` Andrew Morton
2008-05-05 21:07 ` Adrian Bunk
2008-05-05 21:26 ` Andrew Morton
2008-05-05 21:45 ` Adrian Bunk
2008-05-05 21:46 ` Arjan van de Ven
2008-05-06 7:46 ` Andy Whitcroft
2008-05-05 21:02 ` Adrian Bunk
2008-05-06 0:21 ` Andi Kleen [this message]
2008-05-06 6:18 ` [rfc] the kernel workflow & trivial "global -> static" patches Adrian Bunk
2008-05-06 11:13 ` Andi Kleen
2008-05-06 11:25 ` Adrian Bunk
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=874p9ccmes.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ftp.linux.org.uk \
/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