module: don't use stop_machine on module load
authorRusty Russell <rusty@rustcorp.com.au>
Tue, 31 Mar 2009 19:05:35 +0000 (13:05 -0600)
committerRusty Russell <rusty@rustcorp.com.au>
Tue, 31 Mar 2009 02:35:35 +0000 (13:05 +1030)
commite91defa26c527ceeaff6266c55cdc7e17c9081a2
tree03554f76949e5b1bcd4e640a10846d9540b97640
parentacae05156551fd7528fbb616271e672789388e3c
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).

Kay says of this patch:
... no module takes more than 40 millisecs to link now, most of
them are between 3 and 8 millisecs.

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.

Tested-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
kernel/module.c