What is the expected cpu frequency behavior for a Core 2 Duo with Kernel > 4.14?
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What is the expected cpu frequency behavior for a Core 2 Duo with Kernel > 4.14?
I realize there are a ton of threads about this regarding new frequency scaling on new Intel cpu's. I am using a simple Core 2 Duo which is not i-anything, or *Lake whatever. I know those cpu's support a lot of different things and act differently.
My specific processor is a P8400 which supports 800 MHz, 1.60 GHz, and 2.27 GHz. Previously the 'ondemand' option would adjust the frequency as needed, using one of these three frequencies. With newer kernels, the frequency floats all over the place using any imaginable value, changing by the second even when I have nothing intensive running. There is audible noise from the circuitry and battery life is horrible. As far as I can tell these cpus do not support p-state so I've recompiled the kernel, disabling this, but no change.
For now I'm using cpufreq-set in my initrd and setting it to 800 MHz and just leaving it there. And if I go to compile something manually set it to 1.60 GHz.
Is this the expected new behavior or is something broken?
probably that is a forced Intel_Pstate setup and the expected result is standard use of pstate "performance" governor, but it could be "powersave", depends on the Kernel settings.
You can check it with
Code:
cpupower frequency-info
or
cpufreq-info
Should be clearly stated. You can add
Code:
intel_pstate=disable
to your boot parameters to keep using acpi_cpufreq and ondemand governor. Personally I don't like Intel_Pstate and always use acpi_cpufreq.
Some older Intel processors don't work with intel_pstate as they should, and thus should always have the boot parameter intel_pstate=disable. Your processor is most likely one of those.
Adding that boot parameter seemed to have no effect. Also cpufreq-info tells me I'm already using acpi-cpufreq
Code:
username@host:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 4294.55 ms.
hardware limits: 800 MHz - 2.27 GHz
available frequency steps: 2.27 GHz, 2.27 GHz, 1.60 GHz, 800 MHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 2.27 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 2.27 GHz:0.17%, 2.27 GHz:0.01%, 1.60 GHz:1.74%, 800 MHz:98.08% (13372)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 4294.55 ms.
hardware limits: 800 MHz - 2.27 GHz
available frequency steps: 2.27 GHz, 2.27 GHz, 1.60 GHz, 800 MHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 2.27 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 2.27 GHz:0.01%, 2.27 GHz:0.00%, 1.60 GHz:0.00%, 800 MHz:99.99% (2635)
The frequencies are at 800 MHz because I set it with cpufreq-set.
Curiously when using the ondemand governor I've even seen the frequency go beyond 2.27 GHz which can't be good.
Adding that boot parameter seemed to have no effect. Also cpufreq-info tells me I'm already using acpi-cpufreq
Code:
username@host:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 4294.55 ms.
hardware limits: 800 MHz - 2.27 GHz
available frequency steps: 2.27 GHz, 2.27 GHz, 1.60 GHz, 800 MHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 2.27 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 2.27 GHz:0.17%, 2.27 GHz:0.01%, 1.60 GHz:1.74%, 800 MHz:98.08% (13372)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 4294.55 ms.
hardware limits: 800 MHz - 2.27 GHz
available frequency steps: 2.27 GHz, 2.27 GHz, 1.60 GHz, 800 MHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
current policy: frequency should be within 800 MHz and 2.27 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 2.27 GHz:0.01%, 2.27 GHz:0.00%, 1.60 GHz:0.00%, 800 MHz:99.99% (2635)
The frequencies are at 800 MHz because I set it with cpufreq-set.
Curiously when using the ondemand governor I've even seen the frequency go beyond 2.27 GHz which can't be good.
Userspace.. Well. If you are not happy with ondemand, perhaps try "conservative". It is slower to peak and faster to reduce, but other than that it works abit the same way as ondemand. It's my personal favourite.
Expected behaviour with ondemand is normally quite good, while powersave is quite bad and performance pretty much maxes the cpu constantly which entails more heat and higher battery/power consumption.
For a laptop "conservative" is pretty ideal according to my demands.
PS. Kernel v 3.9 was the one where intel_pstate became the default.
I've no bios setting for "Turbo" or similar. In any case a cpu shouldn't be overclocking itself when booted up to a simple MATE desktop sitting idle.
Quote:
Originally Posted by zeebra
Userspace.. Well. If you are not happy with ondemand, perhaps try "conservative". It is slower to peak and faster to reduce, but other than that it works abit the same way as ondemand. It's my personal favourite.
Interestingly "conservative" keeps it at 800 MHz forever. These all seemed fine with kernels 4.4 and before.
Interestingly "conservative" keeps it at 800 MHz forever. These all seemed fine with kernels 4.4 and before.
That depends. It should do until you have some extended heavy tasks, then it will slowly clock up to max speed and stay there as long as needed, then quickly clock down. Try compiling a Kernel for example or some software, you will see.
Not sure what processors you are using, but that didn't do anything here either. I'm guessing support for Core 2 Duo TXXXX and PXXXX is probably formally dead. Unless the kernel folks *seriously* test this out on real hardware, it's time to test out *BSD. Seriously, I'm ... done ... with troubleshooting these new kernels.
Distribution: slackware x86_64 , arm , slackware , AlmaLinux
Posts: 83
Rep:
Hi ,
i have just try to explain how you get rid of the "p-states governor" and come back to use all the other governor's again.
So you may use them with newer kernels and get its funktion's while using the dynamic scaling of frequencies from the p-states backend.
The p-states governor - as i have explained - just do switch between performance and powersave ...
the other things are explained in the diverse dokuments or by the other - here writing - people ...
if you do use "intel_pstate=disable" than these backends of internal cpu freq regulations (by voltage, and many internals more) are totaly switched off ...
Really, I should start reading docs and mucking around with BIOS settings on a 10 year old laptop that worked perfectly until now?
The kernel documentation here explicitly states that the Linux kernel p-state driver is for Sandy Bridge and newer. This, from Wikipedia, means: "the codename for the microarchitecture used in the "second generation" of the Intel Core processors (Core i7, i5, i3)" which I stated in the original post that I am not using.
The instructions you describe such as using "dynamic scaling of frequencies from the p-states backend" isn't going to get exposed for a CPU that the kernel says can't support the p-state driver at all.
a few weeks ago I noticed strange cpu freq on my Core2duo laptop
I don't use it that much, I was re-encoding video and noticed it was slow
looking at cpufreq-info in was ranged 1.20 GHz and 2.40 GHz ondemand
but the current was 632Mhz
I tried changing gov. , rebooting etc. but no change
However a new kernel update arrived and it is now performing as one would expect.
It is currently on a 5.2 kernel, the old one being a 4.19
I have no idea how long it had been affected, it was only when it was under load that I noticed it was slow ( and I don't use it much )
May have stumbled on something. This seems to be more related with timing than frequency scaling itself.
Firerat: You also have the same problem :
"I was re-encoding video and noticed it was slow looking at cpufreq-info in was ranged 1.20 GHz and 2.40 GHz ondemand but the current was 632Mhz"
You shouldn't see odd frequency values like that these processors.
At some point a patch was introduced which disabled a clock source check that these processors need. The patch was reverted at some late date in Kernel 4.19. If your kernel has not been patched try booting with the parameter
clocksource=hpet
This *should* cause you to see only the proper frequency values and not cause any frequency scaling monitors to go crazy. Now, I have not tested enough to know whether this is the only problem. We need to see whether there is any latency issue or whether the frequency in e.g. Ondemand mode lifts off of the lowest value more often than it should.
ondoho: I don't understand why people (try to) use the newest kernel on vintage hardware."
For those who care about software freedom, Core 2 Duo is hardly "vintage hardware" - it's the newest you've got this side of a Rockchip Chromebook that has, oh, I don't know, no ethernet jack and one USB port.
This whole mess and others like it are clearly caused by developers streamlining code and lumping hardware together that clearly does not belong together. Not to mention not actually testing it out first.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
