Part of this arguing with ksplice about their plan for
-ffunction-sections and -fdata-sections got me thinking about how we do
modules. Right at the moment we have one section for every function in
a module, which leads to a massive amount of relocation overhead in the
in-kernel module loader. Plus for some modules (ipv6, I believe), we
lack the relative jumps to get out of the function because we only put
the stubs after all the text sections.
The way to fix all of this, I think, is to make the real linker do more
work. It should be beneficial to us because the linker *should* be able
to rearrange the sections to get the maximum number of jumps satisfiable
relatively.
I've tested that this works on pa8800 systems, but I'd really like
someone to try a failing module on a 32 bit platform (since 64 bits has
22 bit relative jumps, all the modules actually work). You can see some
of the savings in the scsi_mod.ko
Before: 325 sections, 6366 relocation symbols
After: 23 sections, 5244 relocation symbols
James
---
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 55cca1d..ab88f11 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -21,6 +21,7 @@ KBUILD_DEFCONFIG := default_defconfig
NM = sh $(srctree)/arch/parisc/nm
CHECKFLAGS += -D__hppa__=1
+LDFLAGS_MODULE += -T $(srctree)/arch/parisc/kernel/module.lds
MACHINE := $(shell uname -m)
ifeq ($(MACHINE),parisc*)
diff --git a/arch/parisc/kernel/module.lds b/arch/parisc/kernel/module.lds
new file mode 100644
index 0000000..42ee3eb
--- /dev/null
+++ b/arch/parisc/kernel/module.lds
@@ -0,0 +1,6 @@
+SECTIONS {
+ .text : {
+ /* Gather all function sections */
+ *(.text.*)
+ }
+}
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
