public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Jan Beulich <jbeulich@novell.com>
Cc: ccache@lists.samba.org, Theodore Tso <tytso@mit.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc
Date: Wed, 7 Jan 2009 14:23:37 +0100	[thread overview]
Message-ID: <20090107132337.GA2289@uranus.ravnborg.org> (raw)
In-Reply-To: <4964AF8D.76E4.0078.0@novell.com>

On Wed, Jan 07, 2009 at 12:35:09PM +0000, Jan Beulich wrote:
> >>> Sam Ravnborg <sam@ravnborg.org> 07.01.09 12:31 >>>
> >What is the gain/pain ratio here?
> 
> Certainly depends on the pov - it reduces the kernel module (disk) image
> sizes quite a bit, so from a distro perspective its a move against the ever
> growing package sizes (and the disk space) hundreds or even thousands
> of modules require.

The kernel modules seldom export anything so the benefit is minimal here.

I really think we are on a wrong track here.

I did a 15 minutes hack to try ripping the .c -> .s -> .o stuff out.

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 5d90030..8c93dc3 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -153,7 +153,7 @@ $(obj)/%.i: $(src)/%.c FORCE
 
 cmd_genksyms =                                                              \
     $(CPP) -D__GENKSYMS__ $(c_flags) $< |                                   \
-    $(GENKSYMS) -T $@ -A -a $(ARCH)                                         \
+    $(GENKSYMS) -T $@ $(if $(CONFIG_KBUILD_STRIP_CRC), -A) -a $(ARCH)       \
      $(if $(KBUILD_PRESERVE),-p)                                            \
      $(if $(1),-r $(firstword $(wildcard $(@:.symtypes=.symref) /dev/null)))
 
@@ -192,6 +192,7 @@ v_file = $(@D)/.tmp_$(@F:.o=.v)
 tmp_o_file = $(@D)/.tmp_$(@F)
 no_g_c_flags = $(filter-out -g%,$(c_flags))
 
+ifdef CONFIG_KBUILD_STRIP_CRC
 cmd_cc_o_c = $(CC) $(c_flags) -S -o $(s_file) $<
 
 cmd_modversions =							\
@@ -208,8 +209,20 @@ cmd_modversions =							\
 		fi;							\
 	else								\
 		rm -f $(v_file);					\
-		$(CC) $(no_g_c_flags) -c -o $@ $(s_file);		\
+		$(CC) $(no_g_c_flags) -c -o $@ $< ;			\
 	fi;
+else
+cmd_cc_o_c = $(CC) $(c_flags) -c -o $(tmp_o_file) $<
+
+cmd_modversions =							\
+	if $(OBJDUMP) -h $(tmp_o_file) | grep -q __ksymtab; then	\
+		$(call cmd_genksyms, $(KBUILD_SYMTYPES)) > $(v_file);	\
+		$(LD) $(LDFLAGS) -r -o $@ $(tmp_o_file)	-T $(v_file);	\
+	else								\
+		rm -f $(v_file);					\
+	fi;
+
+endif
 endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD


Jan - I need some hard numbers to convince me that stripping the
__crc symbols is worth it.

We can make it a configuration option as I showed above but we should
at least know what we are gaining for this.

I am very positive about stripping of the modules in general,
but the __crc_ symbols seems to trigger a few things:
1) ccahce, distcc issues in the MODVERSION case (that is allmodconfig builds)
2) It does not increase readability of the Makefile machinery and I like more
   people to be able to hack on this - not less.

Thanks,
	Sam

  reply	other threads:[~2009-01-07 13:22 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 [this message]
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
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=20090107132337.GA2289@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=ccache@lists.samba.org \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.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