Bug 463285
Summary: | [LTC 6.0 FEAT] 201240:ACPI C3/C4 Support | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | IBM Bug Proxy <bugproxy> |
Component: | kernel | Assignee: | John Feeney <jfeeney> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Zhang Kexin <kzhang> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.0 | CC: | ejratl, kzhang, notting, peterm, snagar |
Target Milestone: | alpha | Keywords: | FutureFeature, OtherQA |
Target Release: | 6.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | kernel-2.6.32 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-11-15 14:10:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 356741, 495132, 511891, 512362, 512364, 525727, 554559, 555224 |
Description
IBM Bug Proxy
2008-09-22 20:20:47 UTC
This feature request isn't very clear - it says that there are no servers that can be tested with, therefore it's unclear *if* anything needs changed, or what will need to be changed. When do you expect to have hardware available to clarify this? C3/4 has been successfully tested on a couple of laptops with RHEL5.3 pre-alpha kernels. We now have (pre-GA) BIOS support for C3/4 on a couple of upcoming servers. We will hopefully have some upstream results for you within a week or two. C3/4 was testing successfully with mainline (2.6.27.x and 2.6.28-rc) on a couple of System x servers. Given that, setting this to MODIFIED. The feature requested has already been accepted into the upstream code base planned for the next major release of Red Hat Enterprise Linux. When the next milestone release of Red Hat Enterprise Linux 6 is available, please verify that the feature requested is present and functioning as desired. ------- Comment From masbock.com 2010-05-12 11:45 EDT------- I Tested C-State support in RHEL 6 snap2 (2.6.32-23.el6.x86_64) on an IBM x3620 M3 that supports the ACPI C3 state (that equals the Intel C6 state. Tests performed: - verified that the kernel recognizes the C states enabled by the BIOS - checked that the C3 state is entered when the system is idle (through powertop and by directly reading the C-state residency registers on the CPU). Tests passed. I had a look at beaker machine ibm-x3620m3-01.rhts.eng.bos.redhat.com, it does not have c3/c4, I did not look into the bios though. But I did see another ibm-x machine have c3/c4, just for record. ------- Comment From masbock.com 2010-06-17 20:16 EDT------- One system, the IBM HX5 blade so far hasn't successfully resumed from hibernation. Still investigating. ------- Comment From masbock.com 2010-06-17 20:18 EDT------- Sorry, please disregard my last message, I updated the wrong bug. I test C3 state at ibm-x3620m3-01.rhts.eng.bos.redhat.com ,it could enter the C3 state ,but not as expected. 1,cat /proc/acpi/processor/CPU0/power,got the C3 latency 245 2,close all cpus but 0,make system idle 3,run a program wakeup every 245ms,and powertop it it didn't enter the C3 state. When I run a program wakeup every 475ms,it's the first time that C3 state occupys more than 70%. Is this the bug? here is my program 4 int main(int argc,char * argv[]) 5 { 6 if((argc != 2) && (argc != 3)){ 7 printf("useage:sleep_time time\n"); 8 int i; 9 for(i=0;i<argc;i++) 10 printf("argv[%d]:%s\n",i,argv[i]); 11 return -1; 12 } 13 14 while(1) 15 usleep((atoi(argv[1]))); 16 } Hi Peter, Do you think the issue in comment #9 is a problem? thanks! ------- Comment From masbock.com 2010-06-21 17:05 EDT------- (In reply to comment #13) > I test C3 state at ibm-x3620m3-01.rhts.eng.bos.redhat.com ,it could enter the > C3 state ,but not as expected. > 1,cat /proc/acpi/processor/CPU0/power,got the C3 latency 245 > > 2,close all cpus but 0,make system idle > > 3,run a program wakeup every 245ms,and powertop it > > it didn't enter the C3 state. When I run a program wakeup every 475ms,it's the > first time that C3 state occupys more than 70%. > > Is this the bug? I think this is expected. I come to that conclusion after looking at the code and finding a latency_factor module parameter. This factor is used when calculating which C-state to enter. If the expected residency time is greater than latency * latency_factor then the state will be entered. latency_factor is 2 by default. It can be changed with the "processor.latency_factor=<n>" boot parameter. I tried booting with the factors 1 and 3 and saw different C3 residency results as expected. (In reply to comment #12) > ------- Comment From masbock.com 2010-06-21 17:05 EDT------- > (In reply to comment #13) > > I test C3 state at ibm-x3620m3-01.rhts.eng.bos.redhat.com ,it could enter the > > C3 state ,but not as expected. > > 1,cat /proc/acpi/processor/CPU0/power,got the C3 latency 245 > > > > 2,close all cpus but 0,make system idle > > > > 3,run a program wakeup every 245ms,and powertop it > > > > it didn't enter the C3 state. When I run a program wakeup every 475ms,it's the > > first time that C3 state occupys more than 70%. > > > > Is this the bug? > > I think this is expected. I come to that conclusion after looking at the code > and finding a latency_factor module parameter. This factor is used when > calculating which C-state to enter. If the expected residency time is greater > than latency * latency_factor then the state will be entered. latency_factor is > 2 by default. It can be changed with the "processor.latency_factor=<n>" boot > parameter. I tried booting with the factors 1 and 3 and saw different C3 > residency results as expected. this factor is used for cn or just for C3? what the purpose of this factor,and could u tell me where the related code located? thx ------- Comment From masbock.com 2010-06-23 19:05 EDT------- (In reply to comment #16) > this factor is used for cn or just for C3? what the purpose of this factor,and > could u tell me where the related code located? thx latency_factor is declared as a module parameter in drivers/acpi/processor_idle.c. By default it is 2. You can set it at boot time with "processor.latency_factor=<n>". It is used in acpi_processor_setup_cpuidle() to calculate the state->target_residency for each C state as in: state->target_residency = cx->latency * latency_factor; And target_residency is used in menu_select() as follows: /* find the deepest idle state that satisfies our constraints */ for (i = CPUIDLE_DRIVER_STATE_START; i < dev->state_count; i++) { struct cpuidle_state *s = &dev->states[i]; if (s->target_residency > data->predicted_us) break; At least this is how I understand the code at this point. I hope this helps. Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |