Bug 12388 - ondemand on scaling meters differently between Cores 0 and 1 on T8100
Summary: ondemand on scaling meters differently between Cores 0 and 1 on T8100
Status: CLOSED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Alan
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-09 01:46 UTC by James Ettle
Modified: 2011-07-30 05:51 UTC (History)
1 user (show)

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


Attachments
acpidump for Clevo M720R (139.30 KB, text/plain)
2009-02-12 04:02 UTC, James Ettle
Details
cpuinfo on 2.6.27-series (1.39 KB, text/plain)
2009-02-12 04:03 UTC, James Ettle
Details
cpuinfo on 2.6.29-series (1.45 KB, text/plain)
2009-02-12 04:03 UTC, James Ettle
Details
timer_list on 2.6.27-series (4.14 KB, text/plain)
2009-02-12 04:03 UTC, James Ettle
Details
timer_list on 2.6.29-series (10.57 KB, text/plain)
2009-02-12 04:04 UTC, James Ettle
Details

Description James Ettle 2009-01-09 01:46:32 UTC
Latest working kernel version: 2.6.26?
Earliest failing kernel version: Hard to say, some time around 2.6.27.7-8
Distribution: Fedora 10
Hardware Environment: x86-64, Clevo M720R notebook with Intel Core 2 duo T8100 processor, X3100 graphics
Software Environment: x64-64

Problem Description:
On my T8100 notebook, when on AC power, the ondemand governor will only take the processor to full-speed (2.101 GHz) if a demanding job is running on Core 1. If the job is on Core 0, it'll only go up to 2.1 GHz, eventually; it sometimes stops at 1.6 GHz. Either way, scaling up happens more slowly for loads on Core 0. scaling_max_freq is correct at 2101000 in sysfs for both CPUs.

Steps to reproduce:
Boot, apply various loads to either core (nothing special, e.g. encoding Vorbis), and watch for described effect.
Comment 1 ykzhao 2009-02-11 19:21:50 UTC
Will you please cat the output of /proc/timer_list, /proc/cpuinfo, acpidump?
    Thanks.
Comment 2 James Ettle 2009-02-12 04:02:21 UTC
What I've since found is that in the 2.6.27-series kernel, behaviour is as described above, with both CPU cores running at the same frequency. However, on kernel 2.6.29-0.20.rc3.git12.fc10, the cores appear to now scale *independently*, and seem to be doing so correctly according to each core's demand. I'm guessing that the latter is the correct behaviour?

I've attached the requested info below, I hope it's of use. For timer_list and cpuinfo, this has been done for both kernels. Thanks!
Comment 3 James Ettle 2009-02-12 04:02:48 UTC
Created attachment 20208 [details]
acpidump for Clevo M720R
Comment 4 James Ettle 2009-02-12 04:03:09 UTC
Created attachment 20209 [details]
cpuinfo on 2.6.27-series
Comment 5 James Ettle 2009-02-12 04:03:30 UTC
Created attachment 20210 [details]
cpuinfo on 2.6.29-series
Comment 6 James Ettle 2009-02-12 04:03:48 UTC
Created attachment 20211 [details]
timer_list on 2.6.27-series
Comment 7 James Ettle 2009-02-12 04:04:02 UTC
Created attachment 20212 [details]
timer_list on 2.6.29-series
Comment 8 Matthias 2009-02-20 10:18:25 UTC
I have the same problem here with T2330 and Arch Linux but exactly since Kernel 2.6.28.5.
http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=commit;h=412967347f30fbca553485403596f325143e6505
The kernel scales both cores seperately, but they always run with the higher frequency one of them should have. So if one should have 800MHz and the other 1333MHz, both run with 1333MHz.
Because both cores must run with the same speed, the old behaviour should be right.

The cores are still related but don't affect each other anymore:
$ cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/{affected,related}_cpus
0
0 1
1
0 1

Before 2.6.28.5:
$ cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/{affected,related}_cpus
0 1
0 1
0 1
0 1
Comment 9 James Ettle 2009-03-12 18:18:05 UTC
OK, I spoke too soon about the 2.6.29 series, there's still a problem here which I noticed today. The reported clock speed on Core 0 doesn't seem to match its actual clock speed. Lets suppose I run with the ondemand governor. The two cores report different speeds, increasing according to their load. Now, if a demanding job is placed on Core 1, it scales all the way up to (and reports) 2.101 GHz. However if it is on Core 0, again it is *reported* (e.g. in the sysfs entries) to be scaling up to 2.101 GHz, but the job itself runs noticeably slower.
Comment 10 James Ettle 2009-03-14 14:59:45 UTC
Could this be the same as Bug 12763, seen on a T8300 processor? I might give the linked patch a go.
Comment 11 James Ettle 2009-04-30 15:43:20 UTC
I'm going to close this as fixed, since metering appears to be OK now. I'll open another bug for Comment #9, which is due to Core 0 being stuck in T3 throttling state for no apparent good reason.

Note You need to log in before you can comment on or make changes to this bug.