Description of problem: http://cvs.fedora.redhat.com/viewvc/rpms/kernel/F-10/disable-p4-cpufreq-ui.patch disables the /sys api for p4-clockmod. As a consequence, it is impossible to select the performance governor. I need the performance governor because the ondemand governor (the default) makes scrolling in GUI apps and coding in KWrite excruciatingly slow until it detects that the frequency needs to be ramped up. Alternatively I can (have tested in self-built kernels before) tune the lower threshold of ondemand, but the kernel patch you ship disables *that* interface too. WHY? I understand that you would ship ondemand as the default governor, by all means, do! But *DISABLING* the interface for users to change governors and thresholds? Come on! Whoever did this patch, I'm sure without intention, really did not think about the consequences of his work. F10 is the slowest-feeling distribution ever, and (most importantly, thanks to this patch) there's NOTHING you can do about it except recompiling the kernel. Not good. I know Fedora needs to distinguish itself from other distributions. But the way to do that is by adding value, not by removing it. Version-Release number of selected component (if applicable): Linux karen.dragonfear 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53EST 2008 x86_64 x86_64 x86_64 GNU/Linux
BTW, whoever sold you the idea that ondemand is like performance but saves power, was on crack. Yes, there is a *noticeable* performance decrease for several seconds until ondemand catches on.
it shouldn't be using *any* governor. the clockmod code should only be throttling when ACPI indicates that the system needs it due to a thermal event. At all other times, it should be equivalent to the performance governor. (which is also the same as having no governor loaded/set)
You're deflecting, man. Whether the code does whatever you think it should, or not (it DOES NOT, the performance difference is *notorious*), users NEED the userspace API in /sys. Fedora's patch *breaks* this functionality. TL;DR: code does not do what it should do, and even if it did, it breaks the kernel interface.
You're correct that ondemand shouldn't be being run with the p4-clockmod code. That's the bug, not the removal of the userspace interface. The latency of p4-clockmod switching is sufficiently high that ondemand will lead to a noticable performance decrease.
Thanks for recognizing that clockmod switching in Xeons is excruciatingly slowpokeish. But I beg to differ, Matthew. "[the bug is] not the removal of the userspace interface.". WAT? The userspace interface sure looks broken to me! I filed the bug to get the userspace interface back, let me worry about the governors and policies I decide to choose and enact. There is absolutely no reason to patch that functionality out of the kernel -- and I do not see you doling out reasonable justifications for it. For the record, when it's hot in my city, or when I'm going out, I use the userspace interface to load the slowest governor and crank the machine in slow mode. F10's patch broke that for me. So, for me (and very many others out there, I presume) this is a regression.
p4-clockmod is a thermal regulation mechanism, not a speed control or power management mechanism. cpufreq is simply the wrong mechanism to use to provide thermal regulation, so there's no reason to provide the cpufreq UI for p4-clockmod. I have code to add this functionality to the thermal layer, but the p4-clockmod UI will not be returning.
Note that (in theory - I don't have an appropriate machine here to test right now) the CPU speed should still be controllable via /sys/class/thermal/cooling_device*, which is the correct interface to use for thermal control.
> so there's no reason to provide the cpufreq UI for p4-clockmod Well, apparently the kernel guys do see a reason to provide the cpufreq UI for p4-clockmod, self-evident by the fact that the UI ships in the kernel and is used by tons of programs out there that allow the user to set the CPU frequency. Concidentally, I do too. > I have code to add this functionality to the thermal layer, but the p4-clockmod UI will not be returning. You don't understand. It's not the p4-clockmod UI. It's the ENTIRE CPUFREQ UI that you have patched out. I cannot even SWITCH GOVERNORS to performance or powersave! Your alternative UI won't let me crank my machine to 350 MHz, only to 1050 MHz. And it's buggy: changes in one cooling device do not reflect on the other, even though changing just one automatically affects the two cores. As far as I recall, this was one use case that cpufreq handled *correctly*. My use case was simple. Crank the clock down to 350 MHz when I'm not around, so the machine won't sould like a turbine. This neighborhood is extremely quiet, and my neighbors have been waking up like clockwork at about 4:15 AM when the cronjobs fire. But never mind, I got my answer already. I will be recompiling the kernel *with* the removed functionality, probably writing a line or two in my blog giving a technical description of what I did and why I did it, then pushing the kernel to my custom RPM repository. And you still have not given any good reason why the functionalty was stripped, only an academic one that cpufreq should not be used to... control cpu frequency just because cpu frequency correlates with temperature?
cpufreq exists as an in-kernel mechanism to control CPU speed. That mechanism is exposed to userspace in several ways. One of these (the traditional cpufreq UI) is designed to control power. p4-clockmod is not effective in influencing total energy consumption of a system (feel free to ask Intel if you want that confirmed), so providing that interface has always been a bug. The other existing interface is via the thermal layer. It's entirely possible that that has bugs - it certainly hasn't been as well tested. I'll go over the code again to check that it's broadly sensible. We almost removed p4-clockmod from Fedora entirely, since basically every configuration of it will result in a computer that's slower and takes more power. It's been left there purely as a thermal regulation mechanism.
I bought a new rig. Nice 2.666 GHz dual core 64 bit intel. You know, to finish the noise issue. Turns out, I can't play UT anymore: http://www.linuxquestions.org/questions/linux-games-33/ut-99-goty-runs-too-fast....-462106/ Please, do tell me how your allegations as to "the right thing to do about the cpufreq ui" are going to help me play unreal now. Because, you know, it's not like I can edit UT source code to fix this bug, and you removed all possibility of working around it in UT.
I have no idea why I'm encouraging this rant and type of behavior, but NO, UT99 has ALWAYS had this problem on machine with speedstep no matter what, so you fix it the same way we have for YEARS now. [...] # Let's boogie! if [ -x "${UT_DATA_PATH}/ut-bin" ]; then echo "Initializing Unreal engine (ut-bin)" cd "${UT_DATA_PATH}/" if [ "$CPUFREQ" = "ON" ] ; then nice -n18 cat /dev/zero > /dev/null & fbpid=$! "./ut-bin" $* -log kill $fbpid else "./ut-bin" $* -log &>/dev/null fi # always restore proper gamma after an exit or a crash, as UT never gets a chance to if it crashes xgamma -gamma 1.0 &>/dev/null # for general gamma exit 0 fi echo "Couldn't run Unreal Tournament (ut-bin). Check the UT_DATA_PATH above." exit 1
Any modern Intel CPU should be driven with acpi-cpufreq anyway, but the description of the UT bug in the thread you've linked to suggests that the issue here is still that ondemand is being used with p4-clockmod which is (as noted by the fact that this bug is still open) a genuine bug that I'll be working on after Christmas.
Thanks for the quick hack. But the CPU here is not using p4-clockmod: ~@karen α: lsmod | grep clock Sorry, but your fix is not going to fix UT. The real fix would be to have the interface back so I can actually MANUALLY switch to performance, which I should be able to, even if because I want it on a whim.
The interface continues to exist for every cpufreq driver other than p4-clockmod.
So the fact that I do not have the interface is evidence that I have p4-clockmod loaded in my kernel, and the fact that lsmod and /sys files do not show p4-clockmod is loaded is just a fluke? ~@karen α: cat /sys/devices/system/cpu/cpuidle/current_driver acpi_idle
If you do not have any cpufreq interface and are not using p4-clockmod, then you have no cpufreq driver running on your hardware. cpuidle is responsible for putting the processor into idle power states ("C states") and is completely unrelated to cpufreq.
workaround does not work, unreal runs fast, then slow, then fast, then slow, then fast, then slow, in an endless cycle that makes network gameplay impossible. what is the cpufreq driver for my cpu? seems no cpufreq driver wants to load here. All I want is to load the performance governor and peg my CPU to a particular frequency. Is that a tall order?
I've got no idea what the issue you're currently describing is, but it's completely unrelated to the initial bug. Are you sure you were ever using p4-clockmod?
Yes, I was, on the original machine, I found p4-clockmod loaded. On the new machine: /home/rudd-o@karen Ω: modprobe p4-clockmod FATAL: Error inserting p4_clockmod (/lib/modules/2.6.27.7-134.fc10.x86_64/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko): No such device This was the same bug -- until the description of the bug was *edited*.
I don't know how much clearer I can be. No UI has been removed from any component of cpufreq except for p4-clockmod. There are therefore two independent problems here - one is that you somehow seem to be ending up with ondemand even when using p4-clockmod, and the other is that on your new system you have no cpufreq support at all. Please open a separate bug for the second of these problems and include the output of dmesg and find /sys/devices/system/cpu .
That is to say - the fact that p4-clockmod doesn't load on your new system means that p4-clockmod doesn't support your new hardware. The fact that the p4-clockmod UI was removed is therefore entirely unrelated to your current issue. The cpufreq UI is still present for acpi-cpufreq, which is the driver that should be used for your hardware. If acpi-cpufreq doesn't load then that's a bug - however, it has nothing to do with the p4-clockmod UI removal, which was the original subject this bug was filed under, and hence my request that you file a new bug for it.