Bug 12388
Summary: | ondemand on scaling meters differently between Cores 0 and 1 on T8100 | ||
---|---|---|---|
Product: | Power Management | Reporter: | James Ettle (james) |
Component: | cpufreq | Assignee: | Alan (alan) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | lenb |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.29rc | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
acpidump for Clevo M720R
cpuinfo on 2.6.27-series cpuinfo on 2.6.29-series timer_list on 2.6.27-series timer_list on 2.6.29-series |
Description
James Ettle
2009-01-09 01:46:32 UTC
Will you please cat the output of /proc/timer_list, /proc/cpuinfo, acpidump? Thanks. 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! Created attachment 20208 [details]
acpidump for Clevo M720R
Created attachment 20209 [details]
cpuinfo on 2.6.27-series
Created attachment 20210 [details]
cpuinfo on 2.6.29-series
Created attachment 20211 [details]
timer_list on 2.6.27-series
Created attachment 20212 [details]
timer_list on 2.6.29-series
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 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. Could this be the same as Bug 12763, seen on a T8300 processor? I might give the linked patch a go. 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. |