SRU: We could make modprobe less slow by building it with proper CFLAGS

Fixed in intrepid in 3.3-pre11-4ubuntu12.

Regression potential: if we have a serious bug in our toolchain, it could break modprobe; hopefully we'd notice and we'd need to fix our toolchain anyway.

NB: udeb is already built with -Os.

Before the change, idle system, "echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" to both HT logical CPUs:
root@crownbeach:~# time for i in $(seq 100); do modprobe -q foobar; done

real 0m8.720s
user 0m8.357s
sys 0m0.348s

after the change:
root@crownbeach:~# time for i in $(seq 100); do modprobe -q foobar; done

real 0m6.792s
user 0m6.480s
sys 0m0.288s

Package available in my ppa (~lool).

Unconclusive bootcharts follow

Risking to break anything just for a two second boot time improvement? This update would not fix any bug, and thus isn't the obvious candidate for a stable update in my opinion.

If you really need it for e. g. mobile, then I'm ok with uploading it to hardy-proposed and let it sit there for a month or so, and move it over if we don't hear any regression reports.

This change is required for MID and netbook builds, and I would rather we make the change in an SRU than have a different module-init-tools in those builds.

I think putting it into hardy-proposed for an extended period is perfectly reasonable. MID and netbook builds can pull this package in, and it can be thoroughly tested there before being released to hardy-updates.

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

On another system (Thinkpad T60p), before the change:
root@bee:~# echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
root@bee:~# time for i in $(seq 100); do modprobe -q foobar; done

real 0m4.472s
user 0m4.312s
sys 0m0.164s

after the change:
real 0m4.045s
user 0m3.840s
sys 0m0.292s

So testing from -proposed is successful, but the difference is again not huge. Still an easy win it seems. :)

Successfully verified hardy-proposed:

3.3-pre11-4ubuntu5 in hardy
pre500@pristine804:~$ time for i in $(seq 100); do modprobe -q bitblit; done
real 0m0.930s
user 0m0.376s
sys 0m0.544s

3.3-pre11-4ubuntu5.8.04.1 in hardy-proposed
pre500@pristine804:~$ time for i in $(seq 100); do modprobe -q bitblit; done
real 0m0.857s
user 0m0.392s
sys 0m0.464s

Although IMHO the gains offered are not worth the risk of updating such a critical package in LTS.

This has been sitting in -proposed for very long now, and we didn't hear complaints, and got several verifiers. Considering sufficiently verified now.

Copied to hardy-updates.