Bug 13885 - Performance decrease after suspend/resume to ram
Summary: Performance decrease after suspend/resume to ram
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: cpufreq
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2009-08-01 09:26 UTC by marcinzwd
Modified: 2011-04-19 07:49 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.30
Subsystem:
Regression: Yes
Bisected commit-id:

Attachments
Cpuinfo (1.39 KB, application/octet-stream)
2009-08-01 09:27 UTC, marcinzwd 		Details
Very simple performance check (539 bytes, text/x-csrc)
2009-08-01 09:27 UTC, marcinzwd 		Details
dmesg before suspend (15.10 KB, text/plain)
2009-08-01 13:06 UTC, marcinzwd 		Details
dmesg after suspend (13.08 KB, text/plain)
2009-08-01 13:06 UTC, marcinzwd 		Details
Add an attachment (proposed patch, testcase, etc.)

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.
Note You need to log in before you can comment on or make changes to this bug.