Kernel 2.6.30 (probably since 2.6.27)
After suspend/resume there is a huge performance decrease on
my notebook dell d630 with the CPU governor 'ondemand'.
I attached a simple program checkperf.c to assess the
performance and before suspend (or after reboot) I get
time = 0.7050164938 s
time = 2.082638025 s
Moreover if I decrease cpu clock e.g. (cpufreq-set -c 1 -u 2000MHz)
(on second cpu core) then after suspend/resume I get 2.6GHz.
Created attachment 22560 [details]
Created attachment 22561 [details]
Very simple performance check
Is the problem reproducible with the other cpufreq governors?
Not exactly. If I switch to the 'performance' governor then after
suspend/resume cycle I get
time = 0.7349510193 s
So, the difference is negligible.
However, I notice on the 'ondemand' governor that if I run
concurrently two processes "checkpref" (the point is that both
cpu cores are busy) then the performance is back again.
It seems like one cpu core slows down another or
something like that.
I think this is a cpufreq problem, then. Please attach dmesg output from the system, preferably including a suspend/resume cycle as well as boot messages.
Created attachment 22565 [details]
dmesg before suspend
Created attachment 22566 [details]
dmesg after suspend
For the time being I find a simple workaround (not very nice though).
I compile the kernel with default governor 'performance' and
choose the 'ondemand' as a module. Then, after a suspend/resume cycle
I can reload cpufreq_ondemand module and this seems to help.
However, now the 'ondemand' governor works a little bit like 'conservative'
there are noticeable delays between increases and decreases of
the CPU speed.
Marcin, do you agree that this is a regression in cpufreq?
Well, I'm quite sure that with the kernel 18.104.22.168
I didn't have these problems. Although, I needed
to reload the acpi-cpufreq module after a suspend/resume
cycle, because cpufreq didn't work. Then, everything
Is the issue still present in 2.6.37?
bug closed as there is no response from the bug reporter.
please re-open it if the problem still exists in the latest upstream kernel, say 2.6.38.