Bug 463285

Summary: [LTC 6.0 FEAT] 201240:ACPI C3/C4 Support
Product: Red Hat Enterprise Linux 6 Reporter: IBM Bug Proxy <bugproxy>
Component: kernelAssignee: John Feeney <jfeeney>
Status: CLOSED CURRENTRELEASE QA Contact: Zhang Kexin <kzhang>
Severity: high Docs Contact:
Priority: high    
Version: 6.0CC: ejratl, kzhang, notting, peterm, snagar
Target Milestone: alphaKeywords: 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
=Comment: #0=================================================
Emily J. Ratliff <emilyr.com> - 2008-09-16 18:25 EDT
1. Feature Overview:
Feature Id:	[201240]
a. Name of Feature:	ACPI C3/C4 Support
b. Feature Description
Power savings is quickly becoming one of the main focus areas for system x.  We need to ensure
additional ACPI power states (c-states), particularly c3/c4 deep sleep modes, are supported in Linux
so they are ready to be used at the enterprise level, and in support of IBM's power management strategy.

2. Feature Details:
Sponsor:	xSeries
Architectures:
x86
x86_64

Arch Specificity: Both
Affects Core Kernel: Yes
Affects Kernel Modules: Yes
Delivery Mechanism: Direct from community
Category:	Kernel
Request Type:	Kernel - Enhancement from IBM
d. Upstream Acceptance:	Accepted
Sponsor Priority	1
f. Severity: High
IBM Confidential:	no
Code Contribution:	no
g. Component Version Target:	Some of this may just work, because laptops already support this. For
Servers, it must be tested. However, until we have servers that support C3/C4, it's difficult to
guess which upstream kernel any code (if needed) will be targeted for.

3. Business Case
IBM Active Energy Manager will require ACPI C3/C4 Support

4. Primary contact at Red Hat: 
John Jarvis
jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Monte Knutson, mknutson.com, 877-894-1495

Technical contact(s):
Kevin Stansell, kstansel.com
Chris McDermott, mcdermoc.com

IBM Manager:
Julio Alvarez, julioa.com

Comment 1 Bill Nottingham 2008-10-01 20:55:24 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?

Comment 2 IBM Bug Proxy 2008-10-13 20:01:26 UTC
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.

Comment 3 IBM Bug Proxy 2008-11-10 04:50:24 UTC
C3/4 was testing successfully with mainline (2.6.27.x and 2.6.28-rc) on a couple of System x servers.

Comment 4 Bill Nottingham 2008-11-10 19:01:47 UTC
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 6 IBM Bug Proxy 2010-05-12 15:51:33 UTC
------- 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.

Comment 7 Zhang Kexin 2010-06-08 03:32:13 UTC
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 8 IBM Bug Proxy 2010-06-18 00:21:11 UTC
------- 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.

Comment 9 Xiao jing Fang 2010-06-21 04:31:30 UTC
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 }

Comment 10 Zhang Kexin 2010-06-21 05:28:05 UTC
Hi Peter, 
Do you think the issue in comment #9 is a problem?
thanks!

Comment 12 IBM Bug Proxy 2010-06-21 21:11:20 UTC
------- 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.

Comment 13 Xiao jing Fang 2010-06-23 06:36:23 UTC
(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 14 IBM Bug Proxy 2010-06-23 23:10:50 UTC
------- 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.

Comment 15 releng-rhel@redhat.com 2010-11-15 14:10:53 UTC
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.