cpufreq in base

[hiro]

Yeah, that's a step in the right direction. Still I don't understand why you don't just put it in bootsync.sh

[curaga]

It doesn't need to be in sync, so bootlocal would work as well. But so far there haven't been any system commands in bootlocal, it's been all for the user.

[roberts]

I have received curaga's updated loadcpufrq. Look for the blacklist capability in the next cut, 4.7rc2.

[tinypoodle]

We can certainly add the -b option to loadcpufreq's modprobe, so that you can blacklist those modules.

Would there be any chance to also add an option to force loading a module which does not get auto loaded?

[hiro]

tinypoodle just put 'modprobe module' in your bootlocal

from what I understood they're not changing modprobe, but loadcpufreq.

[curaga]

@tinypoodle

I don't understand the request? That sounds like something that would better fit to bootlocal.

[tinypoodle]

"modprobe speedstep_smi" in bootlocal.sh is what I have thus far, and all that is needed to make scaling work.
Interestingly enough, speedstep_lib which appears to be a dependency of speedstep_smi does get autoloaded.

Point in case is that with my setup the cpu will only run at full frequency after speedstep_smi has been loaded, which currently with bootlocal.sh is at a very late point in the boot process.
Therefore with the goal to speed up the boot process I would like to have the module loaded as early as possible and wondered if that could perhaps be done with a somewhat reverse way of blacklisting, by explicitely specifying a module to be loaded.

[curaga]

Certainly a modprobe boot option would be possible, but would it really be useful? Isn't the boot IO-bound even on a P3?

[hiro]

then put it in the first line of bootsync. This is as I said executed *directly* after loadcpufreq.

[hiro]

Or into a tce.installed script of some extension...