[RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

Hi guys,

as you know, systems with custom kernels boot faster, since they don't
need an initramfs or have to install modules. But, building a custom
kernel it is not really practical if you are releasing a distro, for
example.

This patchset aims to eventually solve that problem. It lets you link
external modules statically to the kernel and achive much the same
effect as changing the configuration and recompiling. You only need a
small part of a precompiled kernel tree (20-30MB, debug syms stripped)
and it's fast (15 seconds or less on an ordinary desktop PC).

Status: "Works for me", but has a bunch of TODOs (see below).
However, I hope you can comment on the bits that are done so far.

Thanks,
Andreas

Patches
-------

The patches are against 2.6.29-rc5.

The implementation is quite straightforward. I hope you think the commit
messages in the patches are clear enough.

TODOs
-----

- A makefile target that copies and prunes the tree to minimal
  size. Work in progress.

- Arch-specific changes to kbuild. X86 is done though still ugly so
  it is not included yet. I need to work some more on it first.

- Documentation.

- Proper testing.

How to use this thing in its current state
------------------------------------------

- Enable the new configuration option and build the kernel.
- Install and reboot.
- Collect the pathnames of the loaded modules in a text file
  in the order you want the kernel to initialize them.

  I use the this script. It is a bit slow, but works well
  enough.  (When I remember to run updatedb first.)

-------------8<---------------------------------- 
#!/bin/sh
k_ver="2.6.29-rc4"
for module in `tac /proc/modules`
do
        modname=`echo $module | cut -f 1 -d ' ' | sed -e s/[-_]/[-_]?/g`
        locate --regex /lib/modules/$k_ver/.*/$modname.ko
done
-------------8<----------------------------------

- Preprocess the modules named in the text file
  (called modules.lst here). Run from the kernel tree root:

  scripts/ld_extmodules.sh modules.lst output.o
  
- Relink the kernel:

  e.g make vmlinux L=1 EXTOBJ=output.o
  or 
  make bzImage L=1 EXTOBJ=output.o

- Install it.

- Move the linked modules from /lib/modules/*
  to some other location and run depmod.
  This has to be done so that udev won't try to
  insert them a second time.

- Enjoy.

[RFC PATCH 1/6] New option: Static linking of external modules

[Andreas Robinson]

Define configuration option CONFIG_MODULE_STATIC.
---
 init/Kconfig |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index f068071..dc0f5aa 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1042,6 +1042,27 @@ config MODULE_SRCVERSION_ALL
 	  the version).  With this option, such a "srcversion" field
 	  will be created for all modules.  If unsure, say N.
 
+config MODULE_STATIC
+	bool "Static module linking support (EXPERIMENTAL)"
+	depends on EXPERIMENTAL
+	help
+	  Your computer will start slightly faster if device drivers are
+	  built into the kernel rather than loaded as modules during the
+	  boot process.
+
+	  However, a specialized kernel is impractical to build if the target
+	  hardware configuration is unknown before installation, such as is
+	  the case with generic Linux distributions.
+
+	  If you say Y here, you can build external modules into the kernel,
+	  quickly and without a compiler and with less disk space needed
+	  compared to a fully compiled kernel source tree. Note that your
+	  modules must also be built with this option enabled.
+
+	  See <file:/Documentation/...TODO...> for more details.
+
+	  If unsure, say N.
+
 endif # MODULES
 
 config INIT_ALL_POSSIBLE
-- 
1.5.6.3

[RFC PATCH 2/6] module: add module ELF section with module_init() pointer

[Andreas Robinson]

The linker script will append this section to the end of the list
of initcalls so that init/main.c:do_initcalls() can find it.
---
 include/asm-generic/vmlinux.lds.h |    3 ++-
 include/linux/init.h              |   11 ++++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c61fab1..d3c0787 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -428,7 +428,8 @@
   	*(.initcall6.init)						\
   	*(.initcall6s.init)						\
   	*(.initcall7.init)						\
-  	*(.initcall7s.init)
+  	*(.initcall7s.init)						\
+  	*(.mod_initcall.init)
 
 #define PERCPU(align)							\
 	. = ALIGN(align);						\
diff --git a/include/linux/init.h b/include/linux/init.h
index 68cb026..62b854f 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -284,11 +284,20 @@ void __init parse_early_param(void);
 
 #define security_initcall(fn)		module_init(fn)
 
+#ifdef CONFIG_MODULE_STATIC
+#define module_initcall(fn) \
+	static initcall_t __initcall_##fn \
+	__used __section(.mod_initcall.init) = fn
+#else
+#define module_initcall(fn)
+#endif
+
 /* Each module must use one module_init(). */
 #define module_init(initfn)					\
 	static inline initcall_t __inittest(void)		\
 	{ return initfn; }					\
-	int init_module(void) __attribute__((alias(#initfn)));
+	int init_module(void) __attribute__((alias(#initfn)));	\
+	module_initcall(initfn);
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)					\
-- 
1.5.6.3

[RFC PATCH 3/6] module: always prefix module parameters with the module name

[Andreas Robinson]

The parameters in statically linked modules now end up in the
proper sysfs directories, ie /sys/module/<modname>/parameter/*
---
 include/linux/moduleparam.h |    2 +-
 kernel/params.c             |   17 ++++++++++++++++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index e4af339..0cb2867 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -7,7 +7,7 @@
 
 /* You can override this manually, but generally this should match the
    module name. */
-#ifdef MODULE
+#if defined(MODULE) && !defined(CONFIG_MODULE_STATIC)
 #define MODULE_PARAM_PREFIX /* empty */
 #else
 #define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
diff --git a/kernel/params.c b/kernel/params.c
index a1e3025..22af6ee 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -518,6 +518,19 @@ static void free_module_param_attrs(struct module_kobject *mk)
 	mk->mp = NULL;
 }
 
+#ifdef CONFIG_MODULE_STATIC
+static const char *skip_param_modname(const char *name)
+{
+	const char *dot = strchr(name, '.');
+	return (!dot) ? name : dot + 1;
+}
+#else
+static const char *skip_param_modname(const char *name)
+{
+	return name;
+}
+#endif
+
 /*
  * module_param_sysfs_setup - setup sysfs support for one module
  * @mod: module
@@ -535,9 +548,11 @@ int module_param_sysfs_setup(struct module *mod,
 	bool params = false;
 
 	for (i = 0; i < num_params; i++) {
+		const char *name;
 		if (kparam[i].perm == 0)
 			continue;
-		err = add_sysfs_param(&mod->mkobj, &kparam[i], kparam[i].name);
+		name = skip_param_modname(kparam[i].name);
+		err = add_sysfs_param(&mod->mkobj, &kparam[i], name);
 		if (err)
 			return err;
 		params = true;
-- 
1.5.6.3

[RFC PATCH 4/6] kbuild: allow linking of an external object into vmlinux

[Andreas Robinson]

---
 Makefile |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 22d7584..921d6b4 100644
--- a/Makefile
+++ b/Makefile
@@ -651,7 +651,8 @@ libs-y		:= $(libs-y1) $(libs-y2)
 # Build vmlinux
 # ---------------------------------------------------------------------------
 # vmlinux is built from the objects selected by $(vmlinux-init) and
-# $(vmlinux-main). Most are built-in.o files from top-level directories
+# $(vmlinux-main) and an optional object $(EXTOBJ) specified when
+# running make. Most are built-in.o files from top-level directories
 # in the kernel tree, others are specified in arch/$(ARCH)/Makefile.
 # Ordering when linking is important, and $(vmlinux-init) must be first.
 #
@@ -664,6 +665,8 @@ libs-y		:= $(libs-y1) $(libs-y2)
 #   +--< $(vmlinux-main)
 #   |    +--< driver/built-in.o mm/built-in.o + more
 #   |
+#   +--< $(EXTOBJ) (optional)
+#   |
 #   +-< kallsyms.o (see description in CONFIG_KALLSYMS section)
 #
 # vmlinux version (uname -v) cannot be updated during normal
@@ -686,7 +689,7 @@ export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
 quiet_cmd_vmlinux__ ?= LD      $@
       cmd_vmlinux__ ?= $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
       -T $(vmlinux-lds) $(vmlinux-init)                          \
-      --start-group $(vmlinux-main) --end-group                  \
+      --start-group $(vmlinux-main) $(EXTOBJ) --end-group        \
       $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o FORCE ,$^)
 
 # Generate new vmlinux version
-- 
1.5.6.3

[RFC PATCH 5/6] scripts: new module preprocessor for static linking

[Andreas Robinson]

This script strips unneeded sections, resolves duplicate
symbols and concatenates multiple modules into a single
object file suitable for linking with vmlinux.

Problem: Debug symbols must be stripped or else objcopy
won't remove any sections.
---
 scripts/ld_extmodules.sh |  149 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 149 insertions(+), 0 deletions(-)
 create mode 100755 scripts/ld_extmodules.sh

diff --git a/scripts/ld_extmodules.sh b/scripts/ld_extmodules.sh
new file mode 100755
index 0000000..6049bfd
--- /dev/null
+++ b/scripts/ld_extmodules.sh
@@ -0,0 +1,149 @@
+#!/bin/sh
+# Copyright (C) 2009 Andreas Robinson <andr345@gmail.com>
+#
+# Released under the terms of the GNU GPL v2 or later.
+
+# Usage ###############################
+
+if [ "$#" -ne "2" ]
+then
+
+cat << EOF
+
+Prepare and link a set of modules for static linking with the kernel.
+
+Usage: `basename $0` <modules.lst> <output.o>
+
+<modules.lst> List of modules to link, in insertion order.
+              This is a plain text file with one pathname per line.
+<output.o>    Output object file.
+              You can use modinfo or "readelf -p .modinfo" to read
+              the table of contents.
+
+If the target architecture differs from your host, you must set the
+CROSS_COMPILE environment variable. It is used as a prefix for the
+binutil commands.
+
+EOF
+
+exit 1
+fi
+
+#CROSS_COMPILE=
+LD=${CROSS_COMPILE}ld
+NM=${CROSS_COMPILE}nm
+STRIP=${CROSS_COMPILE}strip
+OBJCOPY=${CROSS_COMPILE}objcopy
+OBJDUMP=${CROSS_COMPILE}objdump
+READELF=${CROSS_COMPILE}readelf
+
+# Helper functions ####################
+
+# Simple "modinfo -F". No need to depend on module-init-tools.
+# $1 = module
+# $2 = field name.
+my_modinfo()
+{
+	${READELF} $1 -p .modinfo | grep -o "$2=.*" | sed s/"$2="//g
+}
+
+# Returns true if module $1 has a GPL compatible license.
+# If a module has more than one license tag, (some do),
+# this function will only look at the first one.
+is_gpl_compatible()
+{
+	license=`my_modinfo $1 license | head -n 1`
+	[ "$license" = "GPL" ] ||
+		[ "$license" = "GPL v2" ] ||
+		[ "$license" = "GPL and additional rights" ] ||
+		[ "$license" = "Dual BSD/GPL" ] ||
+		[ "$license" = "Dual MIT/GPL" ] ||
+		[ "$license" = "Dual MPL/GPL" ]
+}
+
+# Returns true if ELF-file $1 has a section named $2 .
+have_section()
+{
+	[ "`${OBJDUMP} -h $1 | grep -o $2`" != "" ]
+}
+
+# Main ################################
+
+rm -f .tmp_mod* $2
+
+cat $1 | while read module;
+do
+	# Cull unhandled files
+
+	if [ ! -f "$module" ]
+	then
+		echo Skipped: $module - file not found.
+		continue
+	fi
+
+	if ! have_section $module .gnu.linkonce.this_module
+	then
+		echo Skipped: $module - not a kernel module.
+		continue
+	fi
+
+	if ! is_gpl_compatible $module
+	then
+		echo Skipped: $module - not GPL compatible.
+		continue
+	fi
+
+	if ! have_section $module .mod_initcall.init
+	then
+		echo "Warning: `basename $module` has no " \
+			".mod_initcall.init section."
+		echo "         The kernel will not call this " \
+			"module's init function."
+	fi
+
+	# Add to table of contents. (module pathname and srcversion.)
+	printf "module=$module `my_modinfo $module srcversion`\0" \
+		>> .tmp_mod_toc.txt
+
+	# Prepare module for linking with the kernel
+
+	${NM} $module 2> /dev/null | \
+		grep -o "__mod_.*_device_table" > .tmp_mod_devtbl
+
+	${LD} -r --defsym __this_module=0 $module -o .tmp_mod1.o
+
+	${OBJCOPY} --strip-debug                                \
+		--remove-section .gnu.linkonce.this_module      \
+		--remove-section .modinfo                       \
+		--localize-symbol init_module                   \
+		--localize-symbol cleanup_module                \
+		--localize-symbol __this_module                 \
+		.tmp_mod1.o
+
+	if [ ! -f .tmp_mod1.o ]
+	then
+		echo Skipped: $module - objcopy failed.
+		continue
+	fi
+
+	if [ -s .tmp_mod_devtbl ]
+	then
+		${OBJCOPY} --strip-symbols .tmp_mod_devtbl .tmp_mod1.o
+	fi
+
+	# Merge modules into one file.
+
+	if [ ! -f $2 ]; then
+		mv .tmp_mod1.o $2
+	else
+		${LD} -r $2 .tmp_mod1.o -o .tmp_mod2.o
+		mv .tmp_mod2.o $2
+	fi
+
+	echo Merged: $module
+done
+
+# Insert table of contents
+
+${OBJCOPY} --add-section .modinfo=.tmp_mod_toc.txt $2
+
-- 
1.5.6.3

[RFC PATCH 6/6] kbuild: enable relinking of vmlinux without full kernel tree

[Andreas Robinson]

A make parameter "L=1" enables relinking vmlinux from existing
objects. Make will only look at toplevel built-in.o and lib.a.
The source and lower-level objects are ignored.
---
 Makefile |   29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 921d6b4..74a5e5f 100644
--- a/Makefile
+++ b/Makefile
@@ -75,6 +75,17 @@ ifdef M
   endif
 endif
 
+# Use 'make L=1' to skip compilation and relink the existing
+# objects. All objects must exist.
+
+ifdef L
+  ifeq ("$(origin L)", "command line")
+    KBUILD_RELINK := $(L)
+  endif
+endif
+ifndef KBUILD_RELINK
+  KBUILD_RELINK := 0
+endif
 
 # kbuild supports saving output files in a separate directory.
 # To locate output files in a separate directory two syntaxes are supported.
@@ -257,7 +268,7 @@ ifeq ($(MAKECMDGOALS),)
 endif
 
 export KBUILD_MODULES KBUILD_BUILTIN
-export KBUILD_CHECKSRC KBUILD_SRC KBUILD_EXTMOD
+export KBUILD_CHECKSRC KBUILD_SRC KBUILD_EXTMOD KBUILD_RELINK
 
 # Beautify output
 # ---------------------------------------------------------------------------
@@ -459,12 +470,14 @@ else
 # targets and others. In general all targets except *config targets.
 
 ifeq ($(KBUILD_EXTMOD),)
+ifeq ($(KBUILD_RELINK),0)
 # Additional helpers built in scripts/
 # Carefully list dependencies so we do not try to build scripts twice
 # in parallel
 PHONY += scripts
 scripts: scripts_basic include/config/auto.conf
 	$(Q)$(MAKE) $(build)=$(@)
+endif # KBUILD_RELINK
 
 # Objects we will link into vmlinux / subdirs we need to visit
 init-y		:= init/
@@ -692,6 +705,7 @@ quiet_cmd_vmlinux__ ?= LD      $@
       --start-group $(vmlinux-main) $(EXTOBJ) --end-group        \
       $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o FORCE ,$^)
 
+ifeq ($(KBUILD_RELINK),0)
 # Generate new vmlinux version
 quiet_cmd_vmlinux_version = GEN     .version
       cmd_vmlinux_version = set -e;                     \
@@ -703,6 +717,7 @@ quiet_cmd_vmlinux_version = GEN     .version
 	  expr 0$$(cat .old_version) + 1 >.version;	\
 	fi;						\
 	$(MAKE) $(build)=init
+endif
 
 # Generate System.map
 quiet_cmd_sysmap = SYSMAP
@@ -851,6 +866,13 @@ modpost-init := $(filter-out init/built-in.o, $(vmlinux-init))
 vmlinux.o: $(modpost-init) $(vmlinux-main) FORCE
 	$(call if_changed_rule,vmlinux-modpost)
 
+relinked-objs := $(vmlinux-init) $(vmlinux-main) $(vmlinux-lds)
+
+ifeq ($(KBUILD_RELINK),1)
+$(relinked-objs): FORCE
+	$(call if_changed,touch)
+else # The endif is way down. Search for next KBUILD_RELINK.
+
 # The actual objects are generated when descending, 
 # make sure no implicit rule kicks in
 $(sort $(vmlinux-init) $(vmlinux-main)) $(vmlinux-lds): $(vmlinux-dirs) ;
@@ -1234,6 +1256,7 @@ distclean: mrproper
 		-o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
 		-type f -print | xargs rm -f
 
+endif # KBUILD_RELINK
 
 # Packaging of the kernel to various formats
 # ---------------------------------------------------------------------------
@@ -1316,6 +1339,7 @@ help:
 	@echo  '  make O=dir [targets] Locate all output files in "dir", including .config'
 	@echo  '  make C=1   [targets] Check all c source with $$CHECK (sparse by default)'
 	@echo  '  make C=2   [targets] Force check of all c source with $$CHECK'
+	@echo  '  make L=1   [targets] Skip compilation and relink existing objects.'
 	@echo  ''
 	@echo  'Execute "make" or "make all" to build all targets marked with [*] '
 	@echo  'For further info see the ./README file'
@@ -1556,6 +1580,9 @@ a_flags = -Wp,-MD,$(depfile) $(KBUILD_AFLAGS) $(AFLAGS_KERNEL) \
 quiet_cmd_as_o_S = AS      $@
 cmd_as_o_S       = $(CC) $(a_flags) -c -o $@ $<
 
+quiet_cmd_touch = TOUCH   $@
+cmd_touch = if [ -f $@ ]; then touch $@; else echo $@ missing.; exit 1; fi
+
 # read all saved command lines
 
 targets := $(wildcard $(sort $(targets)))
-- 
1.5.6.3

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Monday 16 February 2009 04:50:22 Andreas Robinson wrote:
> Hi guys,
> 
> as you know, systems with custom kernels boot faster, since they don't
> need an initramfs or have to install modules. But, building a custom
> kernel it is not really practical if you are releasing a distro, for
> example.

Hi Andreas,

  This isn't crazy.  But you'd need to benchmark against the minimal
userspace solution: a binary with all the modules built into
it which calls sys_init_module on each one, then does the root swizzle
or whatever.

I think you'd find the difference to be in the noise.

Thanks,
Rusty.

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

On Mon, Feb 16, 2009 at 11:51 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> Hi Andreas,
>
>  This isn't crazy.  But you'd need to benchmark against the minimal
> userspace solution: a binary with all the modules built into
> it which calls sys_init_module on each one, then does the root swizzle
> or whatever.
>
> I think you'd find the difference to be in the noise.

Hi Rusty,

your're right and I'll get right on it.

Cheers,
Andreas

>
> Thanks,
> Rusty.
>

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Tue, Feb 17, 2009 at 11:42, Andreas Robinson <andr345@gmail.com> wrote:
> On Mon, Feb 16, 2009 at 11:51 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>
>>  This isn't crazy.  But you'd need to benchmark against the minimal
>> userspace solution: a binary with all the modules built into
>> it which calls sys_init_module on each one, then does the root swizzle
>> or whatever.
>>
>> I think you'd find the difference to be in the noise.

Usual distro setups load like 100+ modules on every bootup. Modprobing
and symbol-resolving is serialized and uses stop_machine(), so there
might be some significant difference here when loading a huge number
of modules individually. Monolithic versus modular kernels usually
make about 2+ seconds difference on a recent laptop.

> your're right and I'll get right on it.

For distros it's probably more interesting not to get rid of the
initramfs, but possibly have the mkinitrd/mkinitramfs tool to pre-link
all the usual modules if faster bootup is expected. Having only the
few modules pre-linked which are usually included in the initramfs,
might, as Rusty expects, not make that much difference.

Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Tuesday 17 February 2009 22:23:25 Kay Sievers wrote:
> Monolithic versus modular kernels usually
> make about 2+ seconds difference on a recent laptop.

Thanks for the fact injection.  How about a megamodule then?

Cheers,
Rusty.

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Wed, Feb 18, 2009 at 05:58, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Tuesday 17 February 2009 22:23:25 Kay Sievers wrote:
>> Monolithic versus modular kernels usually
>> make about 2+ seconds difference on a recent laptop.
>
> Thanks for the fact injection.  How about a megamodule then?

Sounds interesting. The ability to load multiple modules with a single
call may help, if such a call could be handled faster than individual
calls. Modprobe's modules added by dependencies of the requested
module, or modprobe -a could probably use such a facility.

Or do you think, the time the kernel needs to be locked can be
minimized somehow, so we get more parallelism and less serialization?

The current load_module() wraps ~400 lines of pretty heavy code in
stop_machine(), if we could possibly make that window smaller, so that
multiple instances could prepare some of the work in parallel, and
only a fraction of the current work would need to be serialized?

If that could be improved for the common distro case of running ~90
modprobe calls on bootup, many of them running in parallel, linking
~100 modules in, all in a time-frame of ~2-3 seconds -- that maybe
would attack the real "problem"?

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

It is not in the patchset, but I have code for inserting megamodules
already. So, I can benchmark and compare these setups:

- Monolithic kernel without initramfs.
- Generic with initramfs. insmod'ing all modules.
  (95 of them in this case.)
- Generic with initramfs, insmod'ing a megamodule.

Is there anything else I ought to test?

Time is a bit short today, but I hope to have the results tomorrow night
(CET) at the latest.

/Andreas

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Wednesday 18 February 2009 19:45:21 Kay Sievers wrote:
> On Wed, Feb 18, 2009 at 05:58, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > On Tuesday 17 February 2009 22:23:25 Kay Sievers wrote:
> >> Monolithic versus modular kernels usually
> >> make about 2+ seconds difference on a recent laptop.
> >
> > Thanks for the fact injection.  How about a megamodule then?
> 
> Sounds interesting. The ability to load multiple modules with a single
> call may help, if such a call could be handled faster than individual
> calls. Modprobe's modules added by dependencies of the requested
> module, or modprobe -a could probably use such a facility.

Naah, just create the megamodule in userspace.  It's not terribly hard:
you create a new init which calls all the individual inits, and rename
the module.  You don't supply an "exit" so it can't be unloaded, and for
bonus points remove the .exit sections which will never be used.

I'm handwaving a little, but it would get you all the benefits with no
kernel changes.

Andreas is definitely capable of creating such a thing: it's easier than
what he did with linking in modules!

> The current load_module() wraps ~400 lines of pretty heavy code in
> stop_machine(), if we could possibly make that window smaller, so that
> multiple instances could prepare some of the work in parallel, and
> only a fraction of the current work would need to be serialized?

Module load doesn't use stop_machine (on non-error).  I'm not sure where the code is spending time.  We could shuffle things around so most of load_module doesn't run under the lock, but before that can you tell me if we still lose 2-3 seconds on a UP kernel?

If so, it's not locking, I'd guess it's probably modprobe userspace and reading in the modules from disk, not sys_init_module at all.

Cheers,
Rusty.

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Wed, Feb 18, 2009 at 12:57, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Wednesday 18 February 2009 19:45:21 Kay Sievers wrote:

>> The current load_module() wraps ~400 lines of pretty heavy code in
>> stop_machine(), if we could possibly make that window smaller, so that
>> multiple instances could prepare some of the work in parallel, and
>> only a fraction of the current work would need to be serialized?
>
> Module load doesn't use stop_machine (on non-error).

I see, right. It's only the mutex serializing all module loading work.

> I'm not sure where the code is spending time.  We could shuffle things around
> so most of load_module doesn't run under the lock, but before that can you tell
> me if we still lose 2-3 seconds on a UP kernel?

I tried only my dual core laptop with my "small" kernel and 50
modules, not the crazy distro setup.

I've added stuff like:
   ktime_t in, delta;
   unsigned long long duration;

   in = ktime_get();

   ...

   delta = ktime_sub(ktime_get(), in);
   duration = (unsigned long long) delta.tv64 >> 10;
   printk("XXX: loading %p (%Ld usecs)\n", umod, duration);

across init_module() and some modules wait for 200-500 milliseconds to
get the lock released, some larger modules spend 50 milliseconds in
load_module(), many of them around 20 milliseconds.

> If so, it's not locking, I'd guess it's probably modprobe userspace and reading in
> the modules from disk, not sys_init_module at all.

Bootcharts suggest that it's not I/O bound. We also see this on fast
SSDs and with pre-loading files into RAM. Older modprobe versions did
some heavy fnmatch() over an insanely large distro module.alias file,
which was very CPU expensive, but that got changed recently.

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Thursday 19 February 2009 00:27:58 Kay Sievers wrote:
> some modules wait for 200-500 milliseconds to
> get the lock released, some larger modules spend 50 milliseconds in
> load_module(), many of them around 20 milliseconds.

OK, this is an untested hack (don't try unloading modules, not sure symbol
resolution isn't racy now I've killed the lock).  Does it change the numbers?

Thanks!
Rusty.

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2020,10 +2020,13 @@ static noinline struct module *load_modu
 	}
 #endif
 	if (pcpuindex) {
+		mutex_lock(&module_mutex);
+
 		/* We have a special allocation for this section. */
 		percpu = percpu_modalloc(sechdrs[pcpuindex].sh_size,
 					 sechdrs[pcpuindex].sh_addralign,
 					 mod->name);
+		mutex_unlock(&module_mutex);
 		if (!percpu) {
 			err = -ENOMEM;
 			goto free_percpu;
@@ -2317,19 +2320,10 @@ SYSCALL_DEFINE3(init_module, void __user
 	if (!capable(CAP_SYS_MODULE))
 		return -EPERM;
 
-	/* Only one module load at a time, please */
-	if (mutex_lock_interruptible(&module_mutex) != 0)
-		return -EINTR;
-
 	/* Do all the hard work */
 	mod = load_module(umod, len, uargs);
-	if (IS_ERR(mod)) {
-		mutex_unlock(&module_mutex);
+	if (IS_ERR(mod))
 		return PTR_ERR(mod);
-	}
-
-	/* Drop lock so they can recurse */
-	mutex_unlock(&module_mutex);
 
 	blocking_notifier_call_chain(&module_notify_list,
 			MODULE_STATE_COMING, mod);

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Thu, Feb 19, 2009 at 12:15, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Thursday 19 February 2009 00:27:58 Kay Sievers wrote:
>> some modules wait for 200-500 milliseconds to
>> get the lock released, some larger modules spend 50 milliseconds in
>> load_module(), many of them around 20 milliseconds.
>
> OK, this is an untested hack (don't try unloading modules, not sure symbol
> resolution isn't racy now I've killed the lock).  Does it change the numbers?

That changes it dramatically. The numbers from the sycall until the
linked-in module are now down to 15-25 milliseconds, and for a few
large modules 50-100.

(One crazy exception is ipv6, which takes 620 milliseconds to link, no
idea what it needs to do.)

I'll compare a few bootup times with and without the patch, and come
back later today with the real numbers.

Thanks a lot,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Thu, Feb 19, 2009 at 12:41, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Feb 19, 2009 at 12:15, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> On Thursday 19 February 2009 00:27:58 Kay Sievers wrote:
>>> some modules wait for 200-500 milliseconds to
>>> get the lock released, some larger modules spend 50 milliseconds in
>>> load_module(), many of them around 20 milliseconds.
>>
>> OK, this is an untested hack (don't try unloading modules, not sure symbol
>> resolution isn't racy now I've killed the lock).  Does it change the numbers?
>
> That changes it dramatically. The numbers from the sycall until the
> linked-in module are now down to 15-25 milliseconds, and for a few
> large modules 50-100.
>
> (One crazy exception is ipv6, which takes 620 milliseconds to link, no
> idea what it needs to do.)

Sorry, this was caused by I/O wait from disk for that huge module, and
gets to reasonable numbers by putting all modules into RAM before
loading them.

> I'll compare a few bootup times with and without the patch, and come
> back later today with the real numbers.

The whole massive parallel modprobe happens during udev coldplug. I
tried a 2GHz Dual Core laptop, and a setup without initramfs here,
which loads ~40 modules. All the kernel modules are copied to a ramfs
mount before the coldplug is started.

I measured the time from the first modprobe that happened in the
kernel to the loading of "dummy", which I manually trigger from the
udev boot script, and which gets called right after udev has settled
and handled all events.

With the mutex it takes 1.8 seconds, without it, it takes 1.3 seconds.
If I comment out the creation of the stop_machine() threads, it gets
down to 1.1 seconds.

With the mutex, I see code waiting for up to 180 milliseconds waiting
for the mutex, the average between 20-40 milliseconds.

Without the mutex the largest time to link is 30 milliseconds, and
most of them are around 5-10 milliseconds.

Without the mutex and the stop_machine() creation, the flow of tracing
output looks like real work and, depending on the actual module, they
spend time in various stages of linking, relocation and so on, there
are no long delays for any of the modules, like I see with the current
code.

It would be great, if we can safely minimize the time spent in the mutex.

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Thu, Feb 19, 2009 at 21:48, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Feb 19, 2009 at 12:41, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Thu, Feb 19, 2009 at 12:15, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>> On Thursday 19 February 2009 00:27:58 Kay Sievers wrote:
>>>> some modules wait for 200-500 milliseconds to
>>>> get the lock released, some larger modules spend 50 milliseconds in
>>>> load_module(), many of them around 20 milliseconds.
>>>
>>> OK, this is an untested hack (don't try unloading modules, not sure symbol
>>> resolution isn't racy now I've killed the lock).  Does it change the numbers?
>>
>> That changes it dramatically. The numbers from the sycall until the
>> linked-in module are now down to 15-25 milliseconds, and for a few
>> large modules 50-100.
>>
>> (One crazy exception is ipv6, which takes 620 milliseconds to link, no
>> idea what it needs to do.)
>
> Sorry, this was caused by I/O wait from disk for that huge module, and
> gets to reasonable numbers by putting all modules into RAM before
> loading them.
>
>> I'll compare a few bootup times with and without the patch, and come
>> back later today with the real numbers.
>
> The whole massive parallel modprobe happens during udev coldplug. I
> tried a 2GHz Dual Core laptop, and a setup without initramfs here,
> which loads ~40 modules. All the kernel modules are copied to a ramfs
> mount before the coldplug is started.
>
> I measured the time from the first modprobe that happened in the
> kernel to the loading of "dummy", which I manually trigger from the
> udev boot script, and which gets called right after udev has settled
> and handled all events.
>
> With the mutex it takes 1.8 seconds, without it, it takes 1.3 seconds.
> If I comment out the creation of the stop_machine() threads, it gets
> down to 1.1 seconds.
>
> With the mutex, I see code waiting for up to 180 milliseconds waiting
> for the mutex, the average between 20-40 milliseconds.
>
> Without the mutex the largest time to link is 30 milliseconds, and
> most of them are around 5-10 milliseconds.
>
> Without the mutex and the stop_machine() creation, the flow of tracing
> output looks like real work and, depending on the actual module, they
> spend time in various stages of linking, relocation and so on, there
> are no long delays for any of the modules, like I see with the current
> code.
>
> It would be great, if we can safely minimize the time spent in the mutex.

Further testing revealed, if I only comment out the stop_machine()
preparation, which is used in an error case, I get almost the same
improvement, even with the original mutex in place. Without the mutex
it's still a bit better, maybe it would be much better if we have more
CPUs, but all the long delays are gone only with removing the
stop_machine() preparation.

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

Ok, I've run some tests now and the results are not quite what I expected.

There are 3 cases:

Case 1 used a monolithic kernel with a full set of 95 inked-in
external modules.
Case 2 loaded a single mega-module (same set of 95 modules of course)
while case 3 looped through a list of pathnames and called insmod on
each one.

The test machine boots the monolithic kernel in 6.27 seconds. This is
about 0.5 seconds faster than the other two cases, that were roughly
equal.

The setup:

HP pavillion dv6300 laptop,
TL-56 Turion 64 X2 CPU @1.8GHz, 5400 RPM 2.5" Seagate SATA drive

Linux 2.6.29-rc5, with the .config derived from the generic Ubuntu 8.10 kernel.

All three cases had a minimal initramfs with busybox, insmod and an
init script that only inserted modules and then halted. IOW, no root
fs was mounted.

The results:

1. Monolithic:  6.27 s, (0.22). bzImg=3419 kB ramfs=515 kB
2. Megamodule:  6.80 s, (0.16). bzImg=2297 kB ramfs=1783 kB
3. Insmod list: 6.83 s, (0.07). bzImg=2297 kB ramfs=1942 kB

10 samples were taken in each case. Standard deviations are in parenthesis.
The measured times are printk timestamps from a dummy module inserted last.

Reading these benchmark results I can only conclude that my work is
useless and life has no meaning.

So, what's missing or been done wrong here? I expected the difference
between monolithic and modular to be greater to be honest.

Cheers,
Andreas

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Friday 20 February 2009 08:29:48 Kay Sievers wrote:
> Further testing revealed, if I only comment out the stop_machine()
> preparation, which is used in an error case, I get almost the same
> improvement, even with the original mutex in place. Without the mutex
> it's still a bit better, maybe it would be much better if we have more
> CPUs, but all the long delays are gone only with removing the
> stop_machine() preparation.

Hmm, interesting.  The reason that reducing the lock coverage had this effect
is because stop_machine_create() just bumps a refcount if someone is already
between ...create() and ...destroy().

So, now we've found the problem, let's fix it, then re-visit mutex reduction.

module: don't use stop_machine on module load

Kay Sievers <kay.sievers@vrfy.org> discovered that boot times are slowed
by about half a second because all the stop_machine_create() calls,
and he only probes about 40 modules (I have 125 loaded on this laptop).

We only do stop_machine_create() so we can unlink the module if
something goes wrong, but it's overkill (and buggy anyway: if
stop_machine_create() fails we still call stop_machine_destroy()).

Since we are only protecting against kallsyms (esp. oops) walking the
list, synchronize_sched() is sufficient (synchronize_rcu() is probably
sufficient, but we're not in a hurry).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1881,12 +1881,6 @@ static noinline struct module *load_modu
 	if (len > 64 * 1024 * 1024 || (hdr = vmalloc(len)) == NULL)
 		return ERR_PTR(-ENOMEM);
 
-	/* Create stop_machine threads since the error path relies on
-	 * a non-failing stop_machine call. */
-	err = stop_machine_create();
-	if (err)
-		goto free_hdr;
-
 	if (copy_from_user(hdr, umod, len) != 0) {
 		err = -EFAULT;
 		goto free_hdr;
@@ -2271,12 +2265,13 @@ static noinline struct module *load_modu
 	/* Get rid of temporary copy */
 	vfree(hdr);
 
-	stop_machine_destroy();
 	/* Done! */
 	return mod;
 
  unlink:
-	stop_machine(__unlink_module, mod, NULL);
+	/* Unlink carefully: kallsyms could be walking list. */
+	__list_del(&mod->list);
+	synchronize_sched();
 	module_arch_cleanup(mod);
  cleanup:
 	kobject_del(&mod->mkobj.kobj);
@@ -2297,7 +2292,6 @@ static noinline struct module *load_modu
 	kfree(args);
  free_hdr:
 	vfree(hdr);
-	stop_machine_destroy();
 	return ERR_PTR(err);
 
  truncated:

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Fri, Feb 20, 2009 at 01:58, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Friday 20 February 2009 08:29:48 Kay Sievers wrote:
>> Further testing revealed, if I only comment out the stop_machine()
>> preparation, which is used in an error case, I get almost the same
>> improvement, even with the original mutex in place. Without the mutex
>> it's still a bit better, maybe it would be much better if we have more
>> CPUs, but all the long delays are gone only with removing the
>> stop_machine() preparation.
>
> Hmm, interesting.  The reason that reducing the lock coverage had this effect
> is because stop_machine_create() just bumps a refcount if someone is already
> between ...create() and ...destroy().
>
> So, now we've found the problem, let's fix it, then re-visit mutex reduction.
>
> module: don't use stop_machine on module load
>
> Kay Sievers <kay.sievers@vrfy.org> discovered that boot times are slowed
> by about half a second because all the stop_machine_create() calls,
> and he only probes about 40 modules (I have 125 loaded on this laptop).
>
> We only do stop_machine_create() so we can unlink the module if
> something goes wrong, but it's overkill (and buggy anyway: if
> stop_machine_create() fails we still call stop_machine_destroy()).

Sounds good. With that, no module takes more than 40 millisecs to link
now, most of them are between 3 and 8 millisecs.

Coldplug loads 39 modules, I end up having 50 loaded, but they are
after the udev coldplug settle time. The  39 modules get linked into
the kernel in 281 millisecs, which sounds pretty good.

That looks very different to the numbers without this patch and the
otherwise same setup, where we get heavy noise in the traces and many
delays of up to 200 millisecs until linking, most of them taking 30+
millisecs.

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Fri, Feb 20, 2009 at 01:37, Andreas Robinson <andr345@gmail.com> wrote:
> Ok, I've run some tests now and the results are not quite what I expected.
>
> There are 3 cases:
>
> Case 1 used a monolithic kernel with a full set of 95 inked-in
> external modules.
> Case 2 loaded a single mega-module (same set of 95 modules of course)
> while case 3 looped through a list of pathnames and called insmod on
> each one.
>
> The test machine boots the monolithic kernel in 6.27 seconds. This is
> about 0.5 seconds faster than the other two cases, that were roughly
> equal.
>
> The setup:
>
> HP pavillion dv6300 laptop,
> TL-56 Turion 64 X2 CPU @1.8GHz, 5400 RPM 2.5" Seagate SATA drive
>
> Linux 2.6.29-rc5, with the .config derived from the generic Ubuntu 8.10 kernel.
>
> All three cases had a minimal initramfs with busybox, insmod and an
> init script that only inserted modules and then halted. IOW, no root
> fs was mounted.
>
> The results:
>
> 1. Monolithic:  6.27 s, (0.22). bzImg=3419 kB ramfs=515 kB
> 2. Megamodule:  6.80 s, (0.16). bzImg=2297 kB ramfs=1783 kB
> 3. Insmod list: 6.83 s, (0.07). bzImg=2297 kB ramfs=1942 kB
>
> 10 samples were taken in each case. Standard deviations are in parenthesis.
> The measured times are printk timestamps from a dummy module inserted last.
>
> Reading these benchmark results I can only conclude that my work is
> useless and life has no meaning.
>
> So, what's missing or been done wrong here? I expected the difference
> between monolithic and modular to be greater to be honest.

How do you compare the monolithic kernel? What are the 6.27 seconds
here? The time to boot into /sbin/init without any module load? I
wouldn't be surprised if you just wait in the kernel for some
hardware, driven by a built-in module, to init. Do you use current git
and the "fastboot" commandline option?

I don't think the megamodule will help us much, unless we change the
kernel to parallelize something here, or save some other overhead. It
should not be different from the serial insmods, if the data is not
sprinkled over the disk, which an initramfs isn't. And the
fragmentation problem should not be solved with a mega-module. :)

The general problem is that todays distros start like 100 modprobes in
2 seconds, which does not really compare to a sequential insmod test.

I'm pretty sure, for real-world numbers we need to load them in
parallel, and look at the kernel side, if we can minimize the locked
code area, so we can do as much as possible in parallel.

Only if that is addressed, I think, we can get useful numbers how much
time we really spend in in-kernel linking and can start evaluating if
pre-linking modules would make sense, or not.

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Friday 20 February 2009 11:28:55 Rusty Russell wrote:
> +	/* Unlink carefully: kallsyms could be walking list. */
> +	__list_del(&mod->list);
> +	synchronize_sched();

That should be list_del_rcu() of course.

Rusty.

module: don't use stop_machine on module load

Kay Sievers <kay.sievers@vrfy.org> discovered that boot times are slowed
by about half a second because all the stop_machine_create() calls,
and he only probes about 40 modules (I have 125 loaded on this laptop).

We only do stop_machine_create() so we can unlink the module if
something goes wrong, but it's overkill (and buggy anyway: if
stop_machine_create() fails we still call stop_machine_destroy()).

Since we are only protecting against kallsyms (esp. oops) walking the
list, synchronize_sched() is sufficient (synchronize_rcu() is probably
sufficient, but we're not in a hurry).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 kernel/module.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1881,12 +1881,6 @@ static noinline struct module *load_modu
 	if (len > 64 * 1024 * 1024 || (hdr = vmalloc(len)) == NULL)
 		return ERR_PTR(-ENOMEM);
 
-	/* Create stop_machine threads since the error path relies on
-	 * a non-failing stop_machine call. */
-	err = stop_machine_create();
-	if (err)
-		goto free_hdr;
-
 	if (copy_from_user(hdr, umod, len) != 0) {
 		err = -EFAULT;
 		goto free_hdr;
@@ -2271,12 +2265,13 @@ static noinline struct module *load_modu
 	/* Get rid of temporary copy */
 	vfree(hdr);
 
-	stop_machine_destroy();
 	/* Done! */
 	return mod;
 
  unlink:
-	stop_machine(__unlink_module, mod, NULL);
+	/* Unlink carefully: kallsyms could be walking list. */
+	list_del_rcu(&mod->list);
+	synchronize_sched();
 	module_arch_cleanup(mod);
  cleanup:
 	kobject_del(&mod->mkobj.kobj);
@@ -2297,7 +2292,6 @@ static noinline struct module *load_modu
 	kfree(args);
  free_hdr:
 	vfree(hdr);
-	stop_machine_destroy();
 	return ERR_PTR(err);
 
  truncated:

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

On Fri, 2009-02-20 at 02:55 +0100, Kay Sievers wrote:
> On Fri, Feb 20, 2009 at 01:37, Andreas Robinson <andr345@gmail.com> wrote:

[...]

> > So, what's missing or been done wrong here? I expected the difference
> > between monolithic and modular to be greater to be honest.
> 
> How do you compare the monolithic kernel? What are the 6.27 seconds
> here? The time to boot into /sbin/init without any module load?

It is a wall-time comparison testing how long it takes until all drivers
are initialized.

The last driver to be initialized is a dummy module that merely prints a
timestamp in its init function. That's where the 6.27 seconds come from.

So, the initramfs should have no impact on the monolithic case as it is
not accessed until after the initcalls.

> I wouldn't be surprised if you just wait in the kernel for some
> hardware, driven by a built-in module, to init. Do you use current git
> and the "fastboot" commandline option?

Current git, yes. Fastboot, no, I didn't know it existed! Adding
fastboot, there are dramatic improvements; monolithic boot time is now
3.08 seconds, megamodule is 3.37 and insmod list 3.85. So you are right
to not be surprised. :)

> I don't think the megamodule will help us much, unless we change the
> kernel to parallelize something here, or save some other overhead. It
> should not be different from the serial insmods, if the data is not
> sprinkled over the disk, which an initramfs isn't. And the
> fragmentation problem should not be solved with a mega-module. :)
> 
> The general problem is that todays distros start like 100 modprobes in
> 2 seconds, which does not really compare to a sequential insmod test.
> 
> I'm pretty sure, for real-world numbers we need to load them in
> parallel, and look at the kernel side, if we can minimize the locked
> code area, so we can do as much as possible in parallel.
> 
> Only if that is addressed, I think, we can get useful numbers how much
> time we really spend in in-kernel linking and can start evaluating if
> pre-linking modules would make sense, or not.

Understood. I will parallelize things, add Rusty's patch and see where
we end up!

Cheers,
Andreas

> 
> Thanks,
> Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Fri, Feb 20, 2009 at 12:32, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Friday 20 February 2009 11:28:55 Rusty Russell wrote:
>> +     /* Unlink carefully: kallsyms could be walking list. */
>> +     __list_del(&mod->list);
>> +     synchronize_sched();
>
> That should be list_del_rcu() of course.

Rusty,
are you taking care, that this patch gets merged somewhere, and shows
up in -next?

I still get a ~10% improvement without the mutex, and traces show some
parallelism from different modprobe processes. Any idea how to safely
minimize the time we need to hold it?

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Friday 20 February 2009 11:07:05 Andreas Robinson wrote:
> 1. Monolithic:  6.27 s, (0.22). bzImg=3419 kB ramfs=515 kB
> 2. Megamodule:  6.80 s, (0.16). bzImg=2297 kB ramfs=1783 kB
> 3. Insmod list: 6.83 s, (0.07). bzImg=2297 kB ramfs=1942 kB
> 
> 10 samples were taken in each case. Standard deviations are in parenthesis.
> The measured times are printk timestamps from a dummy module inserted last.
> 
> Reading these benchmark results I can only conclude that my work is
> useless and life has no meaning.

I know that feeling!  Performance work tends to be like that.  I assume this
is an unpatched kernel, or did you apply some of the stop_machine prevention
/ lock reduction patches?
 
> So, what's missing or been done wrong here? I expected the difference
> between monolithic and modular to be greater to be honest.

modprobe vs insmod?

You could try copying /lib/modules/`uname -r`/modules.* and using modprobe,
see if the slowdown is actually there.

Thanks for chasing this!
Rusty.
Rusty.

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Friday 20 February 2009 12:03:57 Kay Sievers wrote:
> That looks very different to the numbers without this patch and the
> otherwise same setup, where we get heavy noise in the traces and many
> delays of up to 200 millisecs until linking, most of them taking 30+
> millisecs.

Hi Kay,
	I've added quotes from your mail and a Tested-by: from you.  It will go
in tomorrow's linux-next.

Thanks!
Rusty.

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Rusty Russell]

On Tuesday 24 February 2009 03:12:28 Kay Sievers wrote:
> Rusty,
> are you taking care, that this patch gets merged somewhere, and shows
> up in -next?

Yep, already done.

> I still get a ~10% improvement without the mutex, and traces show some
> parallelism from different modprobe processes. Any idea how to safely
> minimize the time we need to hold it?

OK, let's do that then.

<hack hack>

Here's a backported version which you should be able to simply apply; it'll
be good to check that we still win...

Thanks!
Rusty.

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -75,7 +75,8 @@ static DECLARE_WAIT_QUEUE_HEAD(module_wq
 
 static BLOCKING_NOTIFIER_HEAD(module_notify_list);
 
-/* Bounds of module allocation, for speeding __module_text_address */
+/* Bounds of module allocation, for speeding __module_address.
+ * Protected by module_mutex. */
 static unsigned long module_addr_min = -1UL, module_addr_max = 0;
 
 int register_module_notifier(struct notifier_block * nb)
@@ -328,7 +329,7 @@ static bool find_symbol_in_section(const
 }
 
 /* Find a symbol, return value, (optional) crc and (optional) module
- * which owns it */
+ * which owns it.  Needs preempt disabled or module_mutex. */
 static unsigned long find_symbol(const char *name,
 				 struct module **owner,
 				 const unsigned long **crc,
@@ -408,8 +409,9 @@ static void *percpu_modalloc(unsigned lo
 {
 	unsigned long extra;
 	unsigned int i;
-	void *ptr;
+	void *ptr = NULL;
 
+	mutex_lock(&module_mutex);
 	if (align > PAGE_SIZE) {
 		printk(KERN_WARNING "%s: per-cpu alignment %li > %li\n",
 		       name, align, PAGE_SIZE);
@@ -434,24 +436,32 @@ static void *percpu_modalloc(unsigned lo
 		ptr += extra;
 
 		/* Split block if warranted */
-		if (pcpu_size[i] - size > sizeof(unsigned long))
-			if (!split_block(i, size))
-				return NULL;
+		if (pcpu_size[i] - size > sizeof(unsigned long)) {
+			if (!split_block(i, size)) {
+				ptr = NULL;
+				break;
+			}
+		}
 
 		/* Mark allocated */
 		pcpu_size[i] = -pcpu_size[i];
-		return ptr;
+		break;
 	}
+	mutex_unlock(&module_mutex);
 
-	printk(KERN_WARNING "Could not allocate %lu bytes percpu data\n",
-	       size);
-	return NULL;
+	if (!ptr)
+		printk(KERN_WARNING
+		       "Could not allocate %lu bytes percpu data\n", size);
+	return ptr;
 }
 
 static void percpu_modfree(void *freeme)
 {
 	unsigned int i;
-	void *ptr = __per_cpu_start + block_size(pcpu_size[0]);
+	void *ptr;
+
+	mutex_lock(&module_mutex);
+	ptr = __per_cpu_start + block_size(pcpu_size[0]);
 
 	/* First entry is core kernel percpu data. */
 	for (i = 1; i < pcpu_num_used; ptr += block_size(pcpu_size[i]), i++) {
@@ -478,6 +488,7 @@ static void percpu_modfree(void *freeme)
 		memmove(&pcpu_size[i+1], &pcpu_size[i+2],
 			(pcpu_num_used - (i+1)) * sizeof(pcpu_size[0]));
 	}
+	mutex_unlock(&module_mutex);
 }
 
 static unsigned int find_pcpusec(Elf_Ehdr *hdr,
@@ -606,7 +617,7 @@ static int already_uses(struct module *a
 	return 0;
 }
 
-/* Module a uses b */
+/* Module a uses b: caller needs module_mutex() */
 static int use_module(struct module *a, struct module *b)
 {
 	struct module_use *use;
@@ -646,6 +657,7 @@ static void module_unload_free(struct mo
 {
 	struct module *i;
 
+	mutex_lock(&module_mutex);
 	list_for_each_entry(i, &modules, list) {
 		struct module_use *use;
 
@@ -661,6 +673,7 @@ static void module_unload_free(struct mo
 			}
 		}
 	}
+	mutex_unlock(&module_mutex);
 }
 
 #ifdef CONFIG_MODULE_FORCE_UNLOAD
@@ -823,9 +836,13 @@ SYSCALL_DEFINE2(delete_module, const cha
 	/* Store the name of the last unloaded module for diagnostic purposes */
 	strlcpy(last_unloaded_module, mod->name, sizeof(last_unloaded_module));
 	unregister_dynamic_debug_module(mod->name);
+
+	/* free_module doesn't want module_mutex held by caller. */
+	mutex_unlock(&module_mutex);
 	free_module(mod);
+	goto out_stop;
 
- out:
+out:
 	mutex_unlock(&module_mutex);
 out_stop:
 	stop_machine_destroy();
@@ -1062,8 +1079,7 @@ static inline int same_magic(const char 
 }
 #endif /* CONFIG_MODVERSIONS */
 
-/* Resolve a symbol for this module.  I.e. if we find one, record usage.
-   Must be holding module_mutex. */
+/* Resolve a symbol for this module.  I.e. if we find one, record usage. */
 static unsigned long resolve_symbol(Elf_Shdr *sechdrs,
 				    unsigned int versindex,
 				    const char *name,
@@ -1073,6 +1089,7 @@ static unsigned long resolve_symbol(Elf_
 	unsigned long ret;
 	const unsigned long *crc;
 
+	mutex_lock(&module_mutex);
 	ret = find_symbol(name, &owner, &crc,
 			  !(mod->taints & (1 << TAINT_PROPRIETARY_MODULE)), true);
 	if (!IS_ERR_VALUE(ret)) {
@@ -1082,6 +1099,7 @@ static unsigned long resolve_symbol(Elf_
 		    !use_module(mod, owner))
 			ret = -EINVAL;
 	}
+	mutex_unlock(&module_mutex);
 	return ret;
 }
 
@@ -1442,11 +1460,14 @@ static int __unlink_module(void *_mod)
 	return 0;
 }
 
-/* Free a module, remove from lists, etc (must hold module_mutex). */
+/* Free a module, remove from lists, etc. */
 static void free_module(struct module *mod)
 {
 	/* Delete from various lists */
+	mutex_lock(&module_mutex);	
 	stop_machine(__unlink_module, mod, NULL);
+	mutex_unlock(&module_mutex);
+
 	remove_notes_attrs(mod);
 	remove_sect_attrs(mod);
 	mod_kobject_remove(mod);
@@ -1520,14 +1541,19 @@ static int verify_export_symbols(struct 
 
 	for (i = 0; i < ARRAY_SIZE(arr); i++) {
 		for (s = arr[i].sym; s < arr[i].sym + arr[i].num; s++) {
+
+			/* Stopping preemption makes find_symbol safe. */
+			preempt_disable();
 			if (!IS_ERR_VALUE(find_symbol(s->name, &owner,
 						      NULL, true, false))) {
+				preempt_enable();
 				printk(KERN_ERR
 				       "%s: exports duplicate symbol %s"
 				       " (owned by %s)\n",
 				       mod->name, s->name, module_name(owner));
 				return -ENOEXEC;
 			}
+			preempt_enable();
 		}
 	}
 	return 0;
@@ -1850,11 +1876,13 @@ static void *module_alloc_update_bounds(
 	void *ret = module_alloc(size);
 
 	if (ret) {
+		mutex_lock(&module_mutex);
 		/* Update module bounds. */
 		if ((unsigned long)ret < module_addr_min)
 			module_addr_min = (unsigned long)ret;
 		if ((unsigned long)ret + size > module_addr_max)
 			module_addr_max = (unsigned long)ret + size;
+		mutex_unlock(&module_mutex);
 	}
 	return ret;
 }
@@ -2256,7 +2284,9 @@ static noinline struct module *load_modu
 	 * function to insert in a way safe to concurrent readers.
 	 * The mutex protects against concurrent writers.
 	 */
+	mutex_lock(&module_mutex);
 	list_add_rcu(&mod->list, &modules);
+	mutex_unlock(&module_mutex);
 
 	err = parse_args(mod->name, mod->args, mod->kp, mod->num_kp, NULL);
 	if (err < 0)
@@ -2275,8 +2305,10 @@ static noinline struct module *load_modu
 	return mod;
 
  unlink:
+	mutex_lock(&module_mutex);
 	/* Unlink carefully: kallsyms could be walking list. */
 	list_del_rcu(&mod->list);
+	mutex_unlock(&module_mutex);
 	synchronize_sched();
 	module_arch_cleanup(mod);
  cleanup:
@@ -2317,19 +2349,10 @@ SYSCALL_DEFINE3(init_module, void __user
 	if (!capable(CAP_SYS_MODULE))
 		return -EPERM;
 
-	/* Only one module load at a time, please */
-	if (mutex_lock_interruptible(&module_mutex) != 0)
-		return -EINTR;
-
 	/* Do all the hard work */
 	mod = load_module(umod, len, uargs);
-	if (IS_ERR(mod)) {
-		mutex_unlock(&module_mutex);
+	if (IS_ERR(mod))
 		return PTR_ERR(mod);
-	}
-
-	/* Drop lock so they can recurse */
-	mutex_unlock(&module_mutex);
 
 	blocking_notifier_call_chain(&module_notify_list,
 			MODULE_STATE_COMING, mod);
@@ -2345,9 +2368,7 @@ SYSCALL_DEFINE3(init_module, void __user
 		module_put(mod);
 		blocking_notifier_call_chain(&module_notify_list,
 					     MODULE_STATE_GOING, mod);
-		mutex_lock(&module_mutex);
 		free_module(mod);
-		mutex_unlock(&module_mutex);
 		wake_up(&module_wq);
 		return ret;
 	}
@@ -2366,14 +2387,15 @@ SYSCALL_DEFINE3(init_module, void __user
 	blocking_notifier_call_chain(&module_notify_list,
 				     MODULE_STATE_LIVE, mod);
 
-	mutex_lock(&module_mutex);
+	/* Be a little careful here: an oops may look at this mem right now. */
+	mod->init_size = 0;
+	mod->init_text_size = 0;
+	wmb();
+	module_free(mod, mod->module_init);
+	mod->module_init = NULL;
+
 	/* Drop initial reference. */
 	module_put(mod);
-	module_free(mod, mod->module_init);
-	mod->module_init = NULL;
-	mod->init_size = 0;
-	mod->init_text_size = 0;
-	mutex_unlock(&module_mutex);
 
 	return 0;
 }

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Wed, Feb 25, 2009 at 08:03, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Tuesday 24 February 2009 03:12:28 Kay Sievers wrote:
>> Rusty,
>> are you taking care, that this patch gets merged somewhere, and shows
>> up in -next?
>
> Yep, already done.

Nice. Thanks!

>> I still get a ~10% improvement without the mutex, and traces show some
>> parallelism from different modprobe processes. Any idea how to safely
>> minimize the time we need to hold it?
>
> OK, let's do that then.
>
> <hack hack>
>
> Here's a backported version which you should be able to simply apply; it'll
> be good to check that we still win...

It's a little bit faster, and the traces show a bit less serialization
and more overlapping code execution.

The difference is very small though, and hard to notice -- loading of
all the 39 modules triggered by a udev coldplug run finishes after
0.23 seconds. After calling init, the last of these modules goes
"live" after 0.26 seconds. Most of the time the modules need is spent
in simplify_symbols().

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

I have finished testing parallel module loading. It looks like a small
kernel with a minimal initramfs and running several instances of insmod
or modprobe in parallel has the best complexity to performance ratio.

Testing shows that a megamodule is slightly slower than parallel
insmods, so it's not really an option anymore.

A monolithic kernel with parallelized initcalls is better - about 200 ms
faster than parallel insmods on my test system. However, it comes with a
fairly large set of changes:

* First, you need a 200-line patch in init/main.c (do_initcalls() and
friends)

* Then the built-in module dependencies must be calculated properly, eg
with a modified depmod, and added to the build process.

* Finally "soft" dependencies, i.e dependencies that are not implied by
symbol use, have to be formalized and moved into the kernel somehow.
Right now they're only defined in "install" commands in modprobe.conf.

So, what do you think, should I keep going? IMHO, the slower userspace
implementation is acceptable since it's so much simpler.

Thanks,
Andreas

------------------------

Here are the test results:

Setup:

HP Pavillion DV6300 laptop. AMD Turion TL-56 @ 1.8GHz CPU. In a
benchmark at Tomshardware, the CPU have scores similar to an Intel core
duo T2300.
http://www.tomshardware.com/reviews/dual-core-notebook-cpus-explored,1553-11.html

Results:

   Configuration                    |   T    | stddev (n = 10)
------------------------------------+--------+--------
[1] Serial monolithic kernel        | 3.08 s |  0.08
[2] Megamodule, serial initcalls    | 3.26 s |  0.05
[3] Megamodule, parallel initcalls  | 2.27 s |  0.01
[4] Parallel insmods w/ mutex patch | 2.20 s |  0.01 <- best choice
[5] Parallel monolithic kernel      | 2.02 s |       <- estimate only

T = Time from kernel startup until all module initcalls have
    executed, i.e when init can mount the root filesystem.

[1] Monolithic 2.6.29-rc5 with fastboot cmdline option. No initramfs.

[2] 94 modules linked into one megamodule. The megamodule executed
    module initcalls sequentially. All files were on a minimal
    initramfs. The kernel had fastboot enabled.

[3] 94 modules inserted with custom insmod, in parallel.
    (Dependencies were accounted for.) Minimal initramfs, fastboot.

[4] Like [2], but initcalls ran in parallel.
    (Dependencies were accounted for.) Minimal initramfs, fastboot.
    Rusty's module loader mutex-patch is applied.

[5] This is an estimation based on how much faster [3] would be if
    load_module() took no time at all. T5 = T3 - (T2 - T1).
    That is, I assume T2-T1 is the time spent in load_module().

Note:

By minimal initramfs, I mean one such that it, plus small kernel, is
roughly the same size as the equivalent monolithic kernel. The only
executable on it is init, written in C. There are no shell scripts,
busybox, progress bars or unused modules.

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Mon, Mar 2, 2009 at 15:32, Andreas Robinson <andr345@gmail.com> wrote:
> I have finished testing parallel module loading. It looks like a small
> kernel with a minimal initramfs and running several instances of insmod
> or modprobe in parallel has the best complexity to performance ratio.
>
> Testing shows that a megamodule is slightly slower than parallel
> insmods, so it's not really an option anymore.

That's what I expected, that we would need more changes, to make a
mega-module working, because we need parallel code execution here.

> A monolithic kernel with parallelized initcalls is better - about 200 ms
> faster than parallel insmods on my test system. However, it comes with a
> fairly large set of changes:
>
> * First, you need a 200-line patch in init/main.c (do_initcalls() and
> friends)
>
> * Then the built-in module dependencies must be calculated properly, eg
> with a modified depmod, and added to the build process.
>
> * Finally "soft" dependencies, i.e dependencies that are not implied by
> symbol use, have to be formalized and moved into the kernel somehow.
> Right now they're only defined in "install" commands in modprobe.conf.
>
> So, what do you think, should I keep going? IMHO, the slower userspace
> implementation is acceptable since it's so much simpler.

I think so too, and think we are fine using the current standard
tools. Also the recent modprobe changes make modprobe very fast by
using a binary index to resolve aliases. I think, we can leave the
stuff as it is.

Seems with the queued stop-machine()-removal patch, and possibly with
the minimized-mutex patch Rusty did, we are fine for now -- at least
with the current numbers, and from a distro's point of view.

Most of the "module load delay" distros see, are likely caused by I/O
loading the module from disk into the kernel, at least that's what my
profiles show. I did all the recent tests (which is a real world udev
coldplug) with a ramfs mount containing a copy of the module
directory, before running the module autoloader. I can link 40 modules
in 0.26 seconds into the kernel with the recent kernel patches.

Thanks for all your testing, it was really helpful, and your patches
have been the reason we've found the stop-machine problem. I'm glad
that we have real numbers now to point people to. It seems, that we
don't need to start fiddling around with hacks in userspace or
initramfs tools.

Thanks a lot,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Arjan van de Ven]

> A monolithic kernel with parallelized initcalls is better - about 200
> ms faster than parallel insmods on my test system. However, it comes
> with a fairly large set of changes:
> 
> * First, you need a 200-line patch in init/main.c (do_initcalls() and
> friends)

why?
We already have async function calls; and those speed up my boot (when
enabled) significantly, by doing much of the kernel/driver init in
parallel.

My server box boots the whole kernel (including all drivers; I build
verything in) in 0.56 seconds, and my net books do it in around 1.0
seconds.

> 
> * Then the built-in module dependencies must be calculated properly,
> eg with a modified depmod, and added to the build process.

nope not if done right

> So, what do you think, should I keep going? IMHO, the slower userspace
> implementation is acceptable since it's so much simpler.

I would strongly suggest that you turn on the async function calls and
look at the boot graph of the resulting kernel boot... if you send
that to me I can also take a look and make suggestions....

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Kay Sievers]

On Mon, Mar 2, 2009 at 17:20, Arjan van de Ven <arjan@infradead.org> wrote:
>> A monolithic kernel with parallelized initcalls is better - about 200
>> ms faster than parallel insmods on my test system. However, it comes
>> with a fairly large set of changes:
>>
>> * First, you need a 200-line patch in init/main.c (do_initcalls() and
>> friends)
>
> why?
> We already have async function calls; and those speed up my boot (when
> enabled) significantly, by doing much of the kernel/driver init in
> parallel.
>
> My server box boots the whole kernel (including all drivers; I build
> verything in) in 0.56 seconds, and my net books do it in around 1.0
> seconds.
>
>>
>> * Then the built-in module dependencies must be calculated properly,
>> eg with a modified depmod, and added to the build process.
>
> nope not if done right
>
>> So, what do you think, should I keep going? IMHO, the slower userspace
>> implementation is acceptable since it's so much simpler.
>
> I would strongly suggest that you turn on the async function calls and
> look at the boot graph of the resulting kernel boot... if you send
> that to me I can also take a look and make suggestions....

The "fastboot" kernel commandline option was used, as mentioned in the
mail. Is there anything else?

Thanks,
Kay

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Arjan van de Ven]

On Mon, 2 Mar 2009 17:29:57 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Mon, Mar 2, 2009 at 17:20, Arjan van de Ven <arjan@infradead.org>
> wrote:
> >> A monolithic kernel with parallelized initcalls is better - about
> >> 200 ms faster than parallel insmods on my test system. However, it
> >> comes with a fairly large set of changes:
> >>
> >> * First, you need a 200-line patch in init/main.c (do_initcalls()
> >> and friends)
> >
> > why?
> > We already have async function calls; and those speed up my boot
> > (when enabled) significantly, by doing much of the kernel/driver
> > init in parallel.
> >
> > My server box boots the whole kernel (including all drivers; I build
> > verything in) in 0.56 seconds, and my net books do it in around 1.0
> > seconds.
> >
> >>
> >> * Then the built-in module dependencies must be calculated
> >> properly, eg with a modified depmod, and added to the build
> >> process.
> >
> > nope not if done right
> >
> >> So, what do you think, should I keep going? IMHO, the slower
> >> userspace implementation is acceptable since it's so much simpler.
> >
> > I would strongly suggest that you turn on the async function calls
> > and look at the boot graph of the resulting kernel boot... if you
> > send that to me I can also take a look and make suggestions....
> 
> The "fastboot" kernel commandline option was used, as mentioned in the
> mail. Is there anything else?

there is some sata level enabling needed depending on the system;
I'd love to see the bootgraph (scripts/bootgraph.pl) for the boot;
that shows exactly what happens when and for how long.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

> there is some sata level enabling needed depending on the system;
> I'd love to see the bootgraph (scripts/bootgraph.pl) for the boot;
> that shows exactly what happens when and for how long.

Hmm, I was going to send you a reply tonight, but it seems I've run out
of time. I'll get back to you as soon as possible, probably tomorrow.

Cheers,
Andreas

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

On Mon, 2009-03-02 at 10:27 -0800, Arjan van de Ven wrote:
> On Mon, 2 Mar 2009 17:29:57 +0100
> Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > On Mon, Mar 2, 2009 at 17:20, Arjan van de Ven <arjan@infradead.org>
> > wrote:

[...]

> > > I would strongly suggest that you turn on the async function calls
> > > and look at the boot graph of the resulting kernel boot... if you
> > > send that to me I can also take a look and make suggestions....
> > 
> > The "fastboot" kernel commandline option was used, as mentioned in the
> > mail. Is there anything else?
> 
> there is some sata level enabling needed depending on the system;
> I'd love to see the bootgraph (scripts/bootgraph.pl) for the boot;
> that shows exactly what happens when and for how long.
> 
Well, this was certainly an eye opener. I can only say thanks for
pointing out bootgraph!

You asked for one graph, but Rusty suggested that I compare insmod and
modprobe (though in another context), so I did more than one.

The (somewhat messy) combined result from booting four initramfs images
with slightly different setups is attached. 

All of them install the 94 modules needed on the test system and all use
2.6.29-rc6 configured like a Ubuntu 8.10 generic kernel. The module
mutex minimizing patch is added, but not the stop_machine patch. (The
merge failed due to my own patches. I need to have a look at it again.)
Fastboot is enabled.

bootgraph.pl was tweaked to, among other things, not stop until when a
dummy module was inserted. This happened after udev had settled and just
before chaining to the file system on the hard drive.

1: (top row, light blue). This installed modules using udev 124 and
modprobe 3.3pre11 that are shipped with Ubuntu 8.10.

2: (second row, light green). This installed modules using the latest
versions of udev (139) and modprobe (3.7pre6) from the git repos.

3: (third row, light yellow). This used a multithreaded insmod. It
employs a very simple method to spawn child processes, so it looks
different from the others and had to be compressed vertically to fit.
(And four processes hang until all initcalls are done and the parent
process dies, so it's kind of buggy too.)

4: (bottom row, pink). This is the megamodule, only added out of
curiosity. It really is multithreaded, but it doesn't use
do_one_initcall() so you can't see anything.


[-- Attachment #2: bootgraph.svg --]
[-- Type: image/svg+xml, Size: 69661 bytes --]

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Arjan van de Ven]

On Wed, 04 Mar 2009 19:47:10 +0100
Andreas Robinson <andr345@gmail.com> wrote:

the only thing I can say (the graphs are a bit complex to read) is that
you are loading a LOT of very expensive modules that bring you no
functionality.
Also I'd love to have seen the scenario where the modules were just
build into the kernel; that gives usually a more reliable indication of
what is going on...


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

fastboot kernel parameter

[Sitsofe Wheeler]

On Mon, Mar 02, 2009 at 08:20:03AM -0800, Arjan van de Ven wrote:
> 
> I would strongly suggest that you turn on the async function calls and

Are async calls only turned on if you boot with the "fastboot" commandline
parameter? If so could a mention of it be added to
kernel-parameters as I don't see anything about it when I glanced at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-parameters.txt;h=54f21a5c262b02ef6cb4718f72b8357693197cf3;hb=HEAD
...

-- 
Sitsofe | http://sucs.org/~sits/

Re: fastboot kernel parameter

[Arjan van de Ven]

On Fri, 6 Mar 2009 07:05:23 +0000
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> On Mon, Mar 02, 2009 at 08:20:03AM -0800, Arjan van de Ven wrote:
> > 
> > I would strongly suggest that you turn on the async function calls
> > and
> 
> Are async calls only turned on if you boot with the "fastboot"
> commandline parameter? If so could a mention of it be added to
> kernel-parameters as I don't see anything about it when I glanced at
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-parameters.txt;h=54f21a5c262b02ef6cb4718f72b8357693197cf3;hb=HEAD
> ...
> 

that's because it's going away again in 2.6.30....


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

On Thu, 2009-03-05 at 16:18 -0800, Arjan van de Ven wrote:
> On Wed, 04 Mar 2009 19:47:10 +0100
> Andreas Robinson <andr345@gmail.com> wrote:
> 
> the only thing I can say (the graphs are a bit complex to read) is that
> you are loading a LOT of very expensive modules that bring you no
> functionality.

Well, yes. It is the generic Ubuntu kernel booting in all its bloaty
glory. :) But this is what most users are stuck with. The distro vendors
won't change their ways because they want their stuff to run on
anything.

So I'm not trying to build a custom kernel just for me. I want to find
ways to have any distro optimize itself to boot in 5-10 seconds on any
computer it has been installed on, without manual configuration. 

> Also I'd love to have seen the scenario where the modules were just
> build into the kernel; that gives usually a more reliable indication of
> what is going on...

Alright, I'm on it.

Cheers,
Andreas

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Arjan van de Ven]

On Fri, 06 Mar 2009 16:15:43 +0100
Andreas Robinson <andr345@gmail.com> wrote:

> On Thu, 2009-03-05 at 16:18 -0800, Arjan van de Ven wrote:
> > On Wed, 04 Mar 2009 19:47:10 +0100
> > Andreas Robinson <andr345@gmail.com> wrote:
> > 
> > the only thing I can say (the graphs are a bit complex to read) is
> > that you are loading a LOT of very expensive modules that bring you
> > no functionality.
> 
> Well, yes. It is the generic Ubuntu kernel booting in all its bloaty
> glory. :) But this is what most users are stuck with. The distro
> vendors won't change their ways because they want their stuff to run
> on anything.

the problem is that you are also having things that just don't make
sense; even for the generalized case...

but I guess that is for Ubuntu to resolve. I don't see the machines I
run (with Fedora) exhibit this same issue; while there are a bunch of
modules, none of the ones that are expensive-and-useless in your charts
are there.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Andreas Robinson]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Fri, 2009-03-06 at 07:45 -0800, Arjan van de Ven wrote: 
> On Fri, 06 Mar 2009 16:15:43 +0100
> Andreas Robinson <andr345@gmail.com> wrote:
> 
> > On Thu, 2009-03-05 at 16:18 -0800, Arjan van de Ven wrote:
> > > On Wed, 04 Mar 2009 19:47:10 +0100
> > > Andreas Robinson <andr345@gmail.com> wrote:
> > > 
> > > the only thing I can say (the graphs are a bit complex to read) is
> > > that you are loading a LOT of very expensive modules that bring you
> > > no functionality.
> > 
> > Well, yes. It is the generic Ubuntu kernel booting in all its bloaty
> > glory. :) But this is what most users are stuck with. The distro
> > vendors won't change their ways because they want their stuff to run
> > on anything.
> 
> the problem is that you are also having things that just don't make
> sense; even for the generalized case...
> 
> but I guess that is for Ubuntu to resolve. I don't see the machines I
> run (with Fedora) exhibit this same issue; while there are a bunch of
> modules, none of the ones that are expensive-and-useless in your charts
> are there.

I think they will. Fast boot is one of the "essential" goals for Jaunty
and Karmic.

Anyway, attached is a bootchart for a cleaned up kernel with the
important (AFAIK) drivers built in.

>From this, I've found some tasks that I can set myself to. They would
obviously be the topic of other threads:

* Make the nforce2 ethernet driver (init_nic) initialize itself
  asynchronously, if possible.

* New config option: Separate initramfs decompression and
  file-system calls. Decompress as early as possible in a
  separate thread.

* Don't unpack initramfs twice. If CONFIG_BLK_DEV_RAM is
  set, the kernel decompresses the ramdisk just to see if
  it's a cpio archive or not, and then throws away the result.

* See what can be done about pci_init(), if anything.

If there's anything else regarding fastboot you think would make more
sense to work on first, please let me know.

Thanks,
Andreas


[-- Attachment #2: hp_bg.svg --]
[-- Type: image/svg+xml, Size: 14687 bytes --]

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Arjan van de Ven]

On Sun, 08 Mar 2009 11:47:17 +0100
Andreas Robinson <andr345@gmail.com> wrote:

> > but I guess that is for Ubuntu to resolve. I don't see the machines
> > I run (with Fedora) exhibit this same issue; while there are a
> > bunch of modules, none of the ones that are expensive-and-useless
> > in your charts are there.
> 
> I think they will. Fast boot is one of the "essential" goals for
> Jaunty and Karmic.
> 
> Anyway, attached is a bootchart for a cleaned up kernel with the
> important (AFAIK) drivers built in.

thanks; very useful overview!

> 
> >From this, I've found some tasks that I can set myself to. They would
> obviously be the topic of other threads:
> 
> * Make the nforce2 ethernet driver (init_nic) initialize itself
>   asynchronously, if possible.

I looked at doing this generically and it is really hard. BUT..
one of the options is to move work from the init to the "ifconfig up"
code...

In addition, for 2.6.30, I have a patch pending to move sata init
before the network init, which can help hide it some
> 
> * New config option: Separate initramfs decompression and
>   file-system calls. Decompress as early as possible in a
>   separate thread.

interesting idea!
> 
> * Don't unpack initramfs twice. If CONFIG_BLK_DEV_RAM is
>   set, the kernel decompresses the ramdisk just to see if
>   it's a cpio archive or not, and then throws away the result.

I actually have a patch for it stuck away somewhere; I thought it was
sent upstream but apparently it was not. I'll dig it out and dust it
off.

Note: Having a smaller initrd (like Fedora does, they make the initrd
only have the modules the specific machine needs) will save a bunch of
time... what isn't there you don't have to decompress either.

> 
> * See what can be done about pci_init(), if anything.
> 
> If there's anything else regarding fastboot you think would make more
> sense to work on first, please let me know.


One thing to mention is that fastinit for sata... I only did AHCI
(because all my machines have that). Your machine looks like it has
something different than AHCI, so maybe the sata controller can use
some work ;-)
(a sata driver needs to opt into parallel scanning via a flag)

SATA init tends to be one of the things that are fix time per drive;
and so working on that first to at least ONLY get that is worth it,
it's a huge chunk of time (more than half the total time in your
bootchart)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

[PATCH] sata_nv: add a module parameter to enable async scanning

[Andreas Robinson]

On Sun, 2009-03-08 at 09:01 -0700, Arjan van de Ven wrote:
> One thing to mention is that fastinit for sata... I only did AHCI
> (because all my machines have that). Your machine looks like it has
> something different than AHCI, so maybe the sata controller can use
> some work ;-)
> (a sata driver needs to opt into parallel scanning via a flag)
> 
> SATA init tends to be one of the things that are fix time per drive;
> and so working on that first to at least ONLY get that is worth it,
> it's a huge chunk of time (more than half the total time in your
> bootchart)

Something like the patch below, mabye? :-)

Before: [    3.056308] Freeing unused kernel memory: 364k freed
After:  [    2.411417] Freeing unused kernel memory: 364k freed

The chipset is nforce2 (drivers/ata/sata_nv.c). I couldn't find
anything like the SSS flag documented in the code, and register
specs from nvidia are as rare as hen's teeth... So I only added
the module parameter to force parallel scans.

I named it parallel_scan instead of ignore_sss though, since
there might not be an SSS-flag to ignore.

/Andreas

>From a5b090856173782308c8f61de84085be9a9b73ba Mon Sep 17 00:00:00 2001
From: Andreas Robinson <andr345@gmail.com>
Date: Sun, 8 Mar 2009 20:44:16 +0100
Subject: [PATCH] sata_nv: add a module parameter to enable async scanning

This parameter (parallel_scan) forces the OS to scan for
disks asynchronously/in parallel, to reduce boot time.

It might cause problems (brown-outs, blown fuses) in
multi-drive systems, if the PSU is unable to handle several
drives spinning up simultaneously.

It ought to be safe in single-drive systems.

Signed-off-by: Andreas Robinson <andr345@gmail.com>
---
 drivers/ata/sata_nv.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index 55a8eed..e8aba2f 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -579,6 +579,7 @@ MODULE_VERSION(DRV_VERSION);
 
 static int adma_enabled;
 static int swncq_enabled = 1;
+static int parallel_scan = 0;
 
 static void nv_adma_register_mode(struct ata_port *ap)
 {
@@ -2427,6 +2428,9 @@ static int nv_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	} else if (type == SWNCQ)
 		nv_swncq_host_init(host);
 
+	if (parallel_scan)
+		host->flags |= ATA_HOST_PARALLEL_SCAN;
+
 	pci_set_master(pdev);
 	return ata_host_activate(host, pdev->irq, ipriv->irq_handler,
 				 IRQF_SHARED, ipriv->sht);
@@ -2526,4 +2530,6 @@ module_param_named(adma, adma_enabled, bool, 0444);
 MODULE_PARM_DESC(adma, "Enable use of ADMA (Default: true)");
 module_param_named(swncq, swncq_enabled, bool, 0444);
 MODULE_PARM_DESC(swncq, "Enable use of SWNCQ (Default: true)");
+module_param_named(parallel_scan, parallel_scan, bool, 0444);
+MODULE_PARM_DESC(parallel_scan, "Force parallel host scan (Default: false)");
 
-- 
1.5.6.3

Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

[Will Newton]

On Sun, Mar 8, 2009 at 4:01 PM, Arjan van de Ven <arjan@infradead.org> wrote:

>> * Don't unpack initramfs twice. If CONFIG_BLK_DEV_RAM is
>>   set, the kernel decompresses the ramdisk just to see if
>>   it's a cpio archive or not, and then throws away the result.
>
> I actually have a patch for it stuck away somewhere; I thought it was
> sent upstream but apparently it was not. I'll dig it out and dust it
> off.

Please do. It's a big win in relative terms compared to the rest of
the boot for small systems.