|Summary:||Performance decrease after suspend/resume to ram|
|Severity:||normal||CC:||akpm, cpufreq, rjw, rui.zhang|
|Bug Depends on:|
Very simple performance check
dmesg before suspend
dmesg after suspend
Description marcinzwd 2009-08-01 09:26:33 UTC
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 after suspend/resume 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.
Comment 2 marcinzwd 2009-08-01 09:27:53 UTC
Created attachment 22561 [details] Very simple performance check
Comment 3 Rafael J. Wysocki 2009-08-01 10:54:23 UTC
Is the problem reproducible with the other cpufreq governors?
Comment 4 marcinzwd 2009-08-01 12:07:23 UTC
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.
Comment 5 Rafael J. Wysocki 2009-08-01 12:28:07 UTC
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.
Comment 8 marcinzwd 2009-08-02 10:07:21 UTC
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.
Comment 9 Andrew Morton 2009-08-03 22:55:58 UTC
Marcin, do you agree that this is a regression in cpufreq? Thanks.
Comment 10 marcinzwd 2009-08-04 10:06:42 UTC
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 worked fine.
Comment 11 Rafael J. Wysocki 2011-01-16 21:59:20 UTC
Is the issue still present in 2.6.37?
Comment 12 Zhang Rui 2011-04-19 07:49:26 UTC
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.