From: "Jan Beulich" <jbeulich@novell.com>
To: "Theodore Tso" <tytso@mit.edu>, "Sam Ravnborg" <sam@ravnborg.org>
Cc: <ccache@lists.samba.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc
Date: Wed, 07 Jan 2009 13:39:38 +0000 [thread overview]
Message-ID: <4964BEAA.76E4.0078.0@novell.com> (raw)
In-Reply-To: <20090107131221.GA17110@mit.edu>
>>> Theodore Tso <tytso@mit.edu> 07.01.09 14:12 >>>
>objcopy: not stripping symbol `__ksymtab_strings' because it is named in a relocation
Another thing I've never seen in any of my builds - these strings always
get relocations against the corresponding section symbol.
>So because it can't safely strip __ksymtab_strings it returns a
>non-zero exit status, and doesn't do anything at all, and then the cp
>command doesn't do any stripping whatso ever.
>
>I could fix this by patching Makefile and scripts/Makefile.modist to
>do this instead:
>
># objcopy --strip-debug --wildcard --strip-symbols /usr/projects/linux/linux-2.6/scripts/strip-symbols fs/xfs/xfs.ko /lib/modules/2.6.28-git7/kernel/fs/xfs/xfs.ko || (cp fs/xfs/xfs.ko /lib/modules/2.6.28-git7/kernel/fs/xfs/xfs.ko ; strip --strip-debug /lib/modules/2.6.28-git7/kernel/fs/xfs/xfs.ko)
I'd rather insert a second objcopy attempt here with just --strip-debug.
>... but at this point, is there going to be any massive downside if I
>just revert commit ad7a953c? Quite frankly, it's causing me a huge
>amount of trouble, and I'm still a bit unclear what the upside of this
>patch is. As near as I can tell there is *single* __crc_ symbol in
>xfs.ko which all of this rigamorale is doing to strip out. From what
>I can tell, not quite doubling the compile time when fully cached by
>ccache, causing INSTALL_MOD_STRIP to fail randomly so that the
>installed modules are a factor of 4 larger, compromising the amount of
>space in my root partition, is all to remove a handful of __crc_*
>symbols from the generated .ko file?
With this and the previous issue I certainly wouldn't mind this and the
subsequent vmlinux stripping patches to be reverted, and I'd aim at
providing an improved version for .30.
>What am I missing? Why is stripping the __crc_* symbols so
>gosh-darned important?
In a separate response I already explained what the goal here is - size
reduction (i.e. making distro package sizes as well as foot print on disk
smaller, thus improving the already existing stripping). And it's not only
about __crc_*, those are just the ones that when removed have the
biggest overall effect. And, as pointed out above, the vmlinux stripping
patch, which has an even more significant effect as it reduces the in-
memory kernel size when using KALLSYMS_ALL, depends on this one.
I have to admit that I generally dislike the tendency for everything to
always only grow, and hence I'm trying to find opportunities to shrink
stuff where possible. I've got a couple of other patches in my local
queue that also aim in that direction, plus there are a few thoughts on
improvements beyond that.
Jan
next prev parent reply other threads:[~2009-01-07 13:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-06 15:15 [REGRESSION] Recent change to kernel spikes out ccache/distcc Theodore Ts'o
2009-01-06 15:29 ` Jan Beulich
2009-01-06 17:33 ` Theodore Tso
2009-01-06 17:48 ` Sam Ravnborg
2009-01-06 18:04 ` Theodore Tso
2009-01-07 8:50 ` Jan Beulich
2009-01-07 11:31 ` Sam Ravnborg
2009-01-07 12:35 ` Jan Beulich
2009-01-07 13:23 ` Sam Ravnborg
2009-01-07 13:48 ` Jan Beulich
2009-01-07 20:06 ` Sam Ravnborg
2009-01-08 19:16 ` Kyle McMartin
2009-01-12 14:06 ` Gilles Espinasse
2009-01-06 17:53 ` Sam Ravnborg
2009-01-06 16:26 ` David Miller
2009-01-06 18:12 ` Theodore Tso
2009-01-06 22:09 ` Sam Ravnborg
2009-01-07 4:33 ` Theodore Tso
2009-01-07 5:10 ` Al Viro
2009-01-07 8:49 ` Jan Beulich
2009-01-07 14:03 ` Al Viro
2009-01-07 14:28 ` Jan Beulich
2009-01-07 14:37 ` Al Viro
2009-01-07 14:40 ` Jan Beulich
2009-01-07 13:12 ` Theodore Tso
2009-01-07 13:39 ` Jan Beulich [this message]
2009-01-07 14:28 ` Theodore Tso
2009-01-07 14:39 ` Jan Beulich
2009-01-08 19:17 ` Dave Jones
2009-01-08 21:31 ` Theodore Tso
2009-01-11 21:48 ` Kyle McMartin
2009-01-11 22:11 ` Theodore Tso
2009-01-11 22:51 ` Theodore Tso
2009-01-11 22:55 ` Kyle McMartin
2009-01-14 17:16 ` Peter Zijlstra
2009-01-15 9:11 ` Jan Beulich
2009-01-15 13:40 ` Theodore Tso
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=4964BEAA.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=ccache@lists.samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=tytso@mit.edu \
/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