cpufreq in base

[hiro]

Can't you make the cpufreq extension separate like in 3.x?

And what's the rationale of loading all cpufreq_* modules?
Where is cpufreq_performance and cpufreq_ondemand?

btw, I just hit the limit of my cmdline length with all the blacklist=xxx I have to put in there.
It took me an hour to realise there's a hidden modprobe in /sbin/loadcpufreq, run by some init scripts.

[tinypoodle]

If I understand right, "performance" is the default governor as configured at compile time, "ondemand" is one of all modular governors to be optionally modprobe'd  at discretion of user.

[netnomad]

hi hiro,

i'm not sure that i understand your problem, because everything works smooth and fine for me.
in my onboot.lst i load cpufreqd.tcz and with tc4.x the cpufreqd is started automatically,
all modules are autoloaded, the standard governor is "ondemand".

in tc3.x i had to start the cpufreqd with the help of my bootlocal.sh:

#su -c "tce-load -w cpufreqd && tce-load -i cpufreqd" tc
#sleep 3
#sudo modprobe acpi-cpufreq
#sudo modprobe cpufreq_ondemand
#sudo modprobe cpufreq_powersave
#sudo cpufreq-set -c 0 -g ondemand
#sudo cpufreq-set -c 1 -g ondemand

this script isn't needed anymore for this standard behavior.

[hiro]

I don't want all that to be run automatically, I have my own scripts, and my own modules.
I have eventually put a hacked loadcpufreq in my backup so I load my modules instead, but this is not how it should be.

[tinypoodle]

I stand corrected: "performance" and "ondemand" are both compiled in, while latter is the default governor.

Unfortunately all modules are not autoloaded i each case - e.g. speedstep-ich being loaded while speedstep-smi requires user intiated loading for frequency scaling to get activated.

I could imagine that there would be usage case scenarios where automatic frequency scaling being automatically activated from base could result in a considerably faster overall boot time - compared to loading by extension as was the case in past.

[curaga]

- current releases also support a comma-separated blacklist format (blacklist=a,b,c)

- the rationale for autoloading those is to save power and heat on most current cpus. It was requested, and was fairly well received in 4.0 - this is the first complaint.

The helper only loads the module for your cpu, or acpi-cpufreq if it can't detect it. But the level of customization you want seems to be difficult with a binary release, why not build your own kernel? It's certainly supported to run TC with custom kernels, and then you could avoid all that blacklisting.

If you build a kernel without alsa, then thinkpad-acpi won't depend on alsa modules either.

[hiro]

Yes, if I had known stuff would get auto loaded in such a nonstandard way (modprobe invocations ignoring blacklists and hidden in some executable for bootup performance reason) I could have built my own linux from scratch in the same time

I was quite happy with the loadable cpufreq extensions on 3.x for a very long time and if you know how it is easy to setup. I also included the phc-intel patches which saves an other Watt or so here. So I'm really not against any efforts to make power saving simple.
I used these things so often that I have built some hacky local extension which automates all my power saving needs in a central place (a combination of several extensions, patched kernel modules and my scripts) for all my PCs. In a way quite comparable with loadcpufreq.
I guess others don't complain because they don't need the fine-grain control and just eat what they get served.

In addition to the kernel modules we also have the cpufreqd and cpufrequtils extensions, which all could have a tce.installed script to do what loadcpufreq currently does.
Instead of concealing the nonstandard automated work users might be just as happy if they get good documentation, or at least optional, and if you like easy-to-use standard extensions.

Of course I would have to give in and build my own private distro if tinycore's motto were "hey, look, my OS boots faster than your's".
But finding a good kernel and maintaining the right patches is difficult and complex for a single person, so please excuse my rants. I hope my actual argument makes sense to you guys.

[hiro]

Perhaps it's not worth it and I'm thinking all in the wrong direction. Now for these things I did having my own personal kernel would have been less work; I'm not sure if i was just lucky that everything worked before this.
But I have also seen quite a lot of upsides for modularizing kernel modules into extensions.

[curaga]

There is no standard way to load cpufreq modules, each distro has their own way. This is currently being fixed in the kernel/udev, so perhaps TC 5 won't need a specific loader for them, as won't other future distros.

But finding a good kernel and maintaining the right patches is difficult and complex for a single person, so please excuse my rants. I hope my actual argument makes sense to you guys.

Why not piggyback on us then? Grab the kernel source we use, and just reconfigure the way you prefer (no alsa, etc). If you already have patched modules, making the jump to a full kernel build should simplify things for you.

But I have also seen quite a lot of upsides for modularizing kernel modules into extensions.

You don't have to lose that - the sorter.sh script is available at the same place as the kernel source. If you tag your kernel as -mine, then you'll get a set of foo-3.0.21-mine.tcz extensions.

[hiro]

Biggest benefits was that without knowing which module *might* get loaded automatically I can be sure it won't when I haven't loaded it into root (even without having to figure out which specific module to block in the blacklists). It also made understanding which module does what or what it depends on more obvious to me.

What I did is certainly just a hack around yet an other automation I don't understand or can't control (the kernel's autoloading of modules). Now this is not possible with cpufreq in base, and because of loadcpufreq even the blacklist is disobeyed.
Instead of 2 ways of keeping a module from autoloading now there is *none*. I'm still reluctant to accept that. Seems like you guys all push towards automation whereas I just try to find ways out of it again

The modules themselves being present is not that big of an issue to most people I guess. They are not as big as crazy stuff like alsa
But loadcpufreq needs to get out of at least that init script. You could put it into bootlocal, which is executed just in the next line IIRC.

So far if I had to personalize anything I could always put it into extensions.
I just have to edit the onboot.lst file to load the right combination of drivers and features on any system I have. That kind of self-containment is appealing to me and is the only real reason I'm still not using only my own private kernels.

For example when I go somewhere else without carrying a byte of data around setting up a specialized terminal for someone is a thing of minutes because I know exactly which minimal set of modules/extensions to (tce-)load. Fast both in terms of administrative work and bandwidth/downloading overhead on the other hand. It would be much more difficult if I had to find and keep up-to-date the all the right kernels with all the right modules and then pull everything together in the multi-level module filetree.

Idealization of some stupid model (especially such a hacky workaround model) doesn't always make sense, but I was able to use it elegantly so far.
My rants could also be read as a success story for tinycore when you look at it from this side

[Rich]

Hi hiro
Maybe you could replace  /sbin/loadcpufreq  with either an empty script or a script that does what you want
and add it to your backup.

[hiro]

that's what I did, Rich. but pretty hacky, no?

I have eventually put a hacked loadcpufreq in my backup so I load my modules instead, but this is not how it should be.

[Rich]

Hi hiro

but pretty hacky, no?

I don't think so. It's the same mechanism you use to replace a stock .conf file with a modified one. A couple of my
TC3.x machines are running a modified version of flwm_topside and that's the same mechanism I use to make
sure my modified version is used. The alternative is to unpack the initrd, make mods, and repack it. As long as
the size of the files you are restoring/replacing does not get out of hand, using the backup function is faster and
easier.

[hiro]

It doesn't fit well into my extension-centric management of different PCs.
I really just use filetool for backups nowadays. Not for persistency.

[curaga]

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