Bug 13885

Summary: Performance decrease after suspend/resume to ram
Product: Power Management Reporter: marcinzwd
Component: cpufreqAssignee: cpufreq
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: akpm, cpufreq, rjw, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.30 Tree: Mainline
Regression: Yes
Bug Depends on:    
Bug Blocks: 7216    
Attachments: Cpuinfo
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 1 marcinzwd 2009-08-01 09:27:07 UTC
Created attachment 22560 [details]
Cpuinfo
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 6 marcinzwd 2009-08-01 13:06:25 UTC
Created attachment 22565 [details]
dmesg before suspend
Comment 7 marcinzwd 2009-08-01 13:06:57 UTC
Created attachment 22566 [details]
dmesg after suspend
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 2.6.27.10
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.