LinuxLists.cc - acpi_idle: Very idle Core i7 machine never enters C3

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, Jan 26, 2010 at 09:41:00PM +0900, peng huang wrote:
> Hi,
> can you show me the file /proc/acpi/processor/CPU*/power.
> and are you sure your cpu usage is 0 or nearly zero.

Yea, I'm pretty sure my cpu usage is nearly zero. powertop shows fewer
than 20 wakeups per second, shows 99% C2 residency, top shows 100% idle,
perf top shows acpi_idle_enter_simple as the most common function
(~50%). Very little is running on the box, and I've compiled out the
heavier parts of the kernel (such as USB)...

(It still has ordinary userspace running, e.g. udev & hal, and still has
sshd and network traffic, as examples.)

This is all consistent with a very idle machine, I think.

> this is the info of my laptop(using core 2 processors):
> powertop's output:
> Cn Avg residency P-states (frequencies)
> C0 (cpu running) (10.6%) 2.00 Ghz 1.9%
> C0 0.0ms ( 0.0%) 1.67 Ghz 0.1%
> C1 mwait 0.0ms ( 0.0%) 1333 Mhz 0.0%
> C2 mwait 0.0ms ( 0.0%) 1000 Mhz 98.0%
> C3 mwait 1.1ms (89.4%)

Yea, my laptop also (also core 2) has 700-1000 wakeups/sec and spends
greater than 80% of its time in C3... That's partly why I'm curious
about what my core i7 desktop is doing.

> and power things:
> huang@huang-laptop:~$ cat /proc/acpi/processor/CPU0/power
> active state: C0
> max_cstate: C8
> maximum allowed latency: 2000000000 usec
> states:
> C1: type[C1] promotion[--] demotion[--]
> latency[001] usage[00002364] duration[00000000000000000000]
> C2: type[C2] promotion[--] demotion[--]
> latency[001] usage[00070662] duration[00000000000006013816]
> C3: type[C3] promotion[--] demotion[--]
> latency[017] usage[04774185] duration[00000000010838418152]
>
> you can see C3 with powertop,so i think your BIOS has enabled Deep
> C-state.

Here's my power files...

/proc/acpi/processor/CPU0/power:
active state: C0
max_cstate: C8
maximum allowed latency: 2000000000 usec
states:
C1: type[C1] promotion[--] demotion[--] latency[001] usage[00001470] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--] latency[017] usage[00234416] duration[00000000017165798539]
C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
/proc/acpi/processor/CPU1/power:
active state: C0
max_cstate: C8
maximum allowed latency: 2000000000 usec
states:
C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000481] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--] latency[017] usage[00090169] duration[00000000017188463157]
C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
/proc/acpi/processor/CPU2/power:
active state: C0
max_cstate: C8
maximum allowed latency: 2000000000 usec
states:
C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000418] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--] latency[017] usage[00068874] duration[00000000017193805291]
C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
/proc/acpi/processor/CPU3/power:
active state: C0
max_cstate: C8
maximum allowed latency: 2000000000 usec
states:
C1: type[C1] promotion[--] demotion[--] latency[001] usage[00001356] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--] latency[017] usage[00362752] duration[00000000017156707397]
C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]

>
> -huang
>
> 2010-01-26 (火) の 02:47 -0600 に Jeff Garrett さんは書きました:
> > Hi,
> >
> > I was trying to chase down a theory that my desktop machine (a core i7)
> > is running warm (the fan sounds like it's at full speed all the time,
> > and I think it's not always acted this way -- hence the theory).
> >
> > powertop is never showing it spending any time in C3...
> >
> > I compiled a kernel without USB/sound/radeon, and ran without X. I was
> > able to get the wakeups/sec down below 20, but no time is spent in C3.
> >
> > sysfs looks to agree with powertop here (time = 0 on C3):
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/latency: 0
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/name: C0
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/power: 4294967295
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/time: 457
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/usage: 59
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/desc: ACPI FFH INTEL MWAIT 0x0
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/latency: 1
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/name: C1
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/power: 1000
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/time: 308177
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/usage: 3975
> > /sys/devices/system/cpu/cpu0/cpuidle/state2/desc: ACPI FFH INTEL MWAIT 0x10
> > /sys/devices/system/cpu/cpu0/cpuidle/state2/latency: 17
> > /sys/devices/system/cpu/cpu0/cpuidle/state2/name: C2
> > /sys/devices/system/cpu/cpu0/cpuidle/state2/power: 500
> > /sys/devices/system/cpu/cpu0/cpuidle/state2/time: 873440787
> > /sys/devices/system/cpu/cpu0/cpuidle/state2/usage: 239038
> > /sys/devices/system/cpu/cpu0/cpuidle/state3/desc: ACPI FFH INTEL MWAIT 0x20
> > /sys/devices/system/cpu/cpu0/cpuidle/state3/latency: 17
> > /sys/devices/system/cpu/cpu0/cpuidle/state3/name: C3
> > /sys/devices/system/cpu/cpu0/cpuidle/state3/power: 350
> > /sys/devices/system/cpu/cpu0/cpuidle/state3/time: 0
> > /sys/devices/system/cpu/cpu0/cpuidle/state3/usage: 0
> >
> > This may be a complete red herring, but I added some printk logic to
> > acpi_idle_bm_check(), and it is getting called often, but bm_status is
> > always 1. [I infer from this that the idle logic is trying to go into
> > C3, but this check is stopping it... Unless I misread something.]
> >
> > Is this expected behavior or is this a legitimate problem?
> >
> > How might I investigate this further?
> >
> > Attaching dmesg, /proc/cpuinfo, powertop -d output.
> >
> > Thanks,
> > Jeff Garrett
>
>
> --
> peng huang <[email protected]>
>

2010-01-26 21:45:34

by Andi Kleen

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

[email protected] (Jeff Garrett) writes:

> Hi,
>
> I was trying to chase down a theory that my desktop machine (a core i7)
> is running warm (the fan sounds like it's at full speed all the time,
> and I think it's not always acted this way -- hence the theory).
>
> powertop is never showing it spending any time in C3...
>
> I compiled a kernel without USB/sound/radeon, and ran without X. I was
> able to get the wakeups/sec down below 20, but no time is spent in C3.

[...]
> This may be a complete red herring, but I added some printk logic to
> acpi_idle_bm_check(), and it is getting called often, but bm_status is
> always 1. [I infer from this that the idle logic is trying to go into
> C3, but this check is stopping it... Unless I misread something.]

Normally a Core i7 (or any modern Intel systems) should not use
bm_check at all. That's only for older systems that didn't support
MWAIT with c-state hint, but relied on the old port based interface.

So something is already confused there.

I think it should still work though.
Of course if you really have a lot of bus mastering in the background
then yes there will be no C3.

-Andi

--
[email protected] -- Speaking for myself only.

2010-01-27 13:27:25

by peng huang

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

2010-01-26 (火) の 08:59 -0600 に Jeff Garrett さんは書きました:
> On Tue, Jan 26, 2010 at 09:41:00PM +0900, peng huang wrote:
> > Hi,
> > can you show me the file /proc/acpi/processor/CPU*/power.
> > and are you sure your cpu usage is 0 or nearly zero.
>
> Yea, I'm pretty sure my cpu usage is nearly zero. powertop shows fewer
> than 20 wakeups per second, shows 99% C2 residency, top shows 100% idle,
> perf top shows acpi_idle_enter_simple as the most common function
> (~50%). Very little is running on the box, and I've compiled out the
> heavier parts of the kernel (such as USB)...
>
> (It still has ordinary userspace running, e.g. udev & hal, and still has
> sshd and network traffic, as examples.)
>
> This is all consistent with a very idle machine, I think.

yes,you processor is always in c2,it does means your system is nearly
ilde.

> > this is the info of my laptop(using core 2 processors):
> > powertop's output:
> > Cn Avg residency P-states (frequencies)
> > C0 (cpu running) (10.6%) 2.00 Ghz 1.9%
> > C0 0.0ms ( 0.0%) 1.67 Ghz 0.1%
> > C1 mwait 0.0ms ( 0.0%) 1333 Mhz 0.0%
> > C2 mwait 0.0ms ( 0.0%) 1000 Mhz 98.0%
> > C3 mwait 1.1ms (89.4%)
>
> Yea, my laptop also (also core 2) has 700-1000 wakeups/sec and spends
> greater than 80% of its time in C3... That's partly why I'm curious
> about what my core i7 desktop is doing.

So I think it is a core i7 thing.I have heard that some intel cpu have a
problem when in c2-state,maybe that is why you cpu cant enter c3-state.
I think there is some configuration about deep c-state in the bios,may
be you can try it(it cannot solve this problem...).
And in some bios there is a enhanced idle state configuration ,but i
dont known if it is the reason why the cpu cannot enter c3-state.You can
try it anyway.

With disable the deep c-state you BIOS will not give c3-info to the
OS,then you would see there is no c3-state in the OS.

> > and power things:
> > huang@huang-laptop:~$ cat /proc/acpi/processor/CPU0/power
> > active state: C0
> > max_cstate: C8
> > maximum allowed latency: 2000000000 usec
> > states:
> > C1: type[C1] promotion[--] demotion[--]
> > latency[001] usage[00002364] duration[00000000000000000000]
> > C2: type[C2] promotion[--] demotion[--]
> > latency[001] usage[00070662] duration[00000000000006013816]
> > C3: type[C3] promotion[--] demotion[--]
> > latency[017] usage[04774185] duration[00000000010838418152]
> >
> > you can see C3 with powertop,so i think your BIOS has enabled Deep
> > C-state.
>
> Here's my power files...
>
> /proc/acpi/processor/CPU0/power:
> active state: C0
> max_cstate: C8
> maximum allowed latency: 2000000000 usec
> states:
> C1: type[C1] promotion[--] demotion[--] latency[001] usage[00001470] duration[00000000000000000000]
> C2: type[C2] promotion[--] demotion[--] latency[017] usage[00234416] duration[00000000017165798539]
> C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
> /proc/acpi/processor/CPU1/power:
> active state: C0
> max_cstate: C8
> maximum allowed latency: 2000000000 usec
> states:
> C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000481] duration[00000000000000000000]
> C2: type[C2] promotion[--] demotion[--] latency[017] usage[00090169] duration[00000000017188463157]
> C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
> /proc/acpi/processor/CPU2/power:
> active state: C0
> max_cstate: C8
> maximum allowed latency: 2000000000 usec
> states:
> C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000418] duration[00000000000000000000]
> C2: type[C2] promotion[--] demotion[--] latency[017] usage[00068874] duration[00000000017193805291]
> C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
> /proc/acpi/processor/CPU3/power:
> active state: C0
> max_cstate: C8
> maximum allowed latency: 2000000000 usec
> states:
> C1: type[C1] promotion[--] demotion[--] latency[001] usage[00001356] duration[00000000000000000000]
> C2: type[C2] promotion[--] demotion[--] latency[017] usage[00362752] duration[00000000017156707397]
> C3: type[C3] promotion[--] demotion[--] latency[017] usage[00000000] duration[00000000000000000000]
>
> >
> > -huang
> >
> > 2010-01-26 (火) の 02:47 -0600 に Jeff Garrett さんは書きました:
> > > Hi,
> > >
> > > I was trying to chase down a theory that my desktop machine (a core i7)
> > > is running warm (the fan sounds like it's at full speed all the time,
> > > and I think it's not always acted this way -- hence the theory).
> > >
> > > powertop is never showing it spending any time in C3...
> > >
> > > I compiled a kernel without USB/sound/radeon, and ran without X. I was
> > > able to get the wakeups/sec down below 20, but no time is spent in C3.
> > >
> > > sysfs looks to agree with powertop here (time = 0 on C3):
> > > /sys/devices/system/cpu/cpu0/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE
> > > /sys/devices/system/cpu/cpu0/cpuidle/state0/latency: 0
> > > /sys/devices/system/cpu/cpu0/cpuidle/state0/name: C0
> > > /sys/devices/system/cpu/cpu0/cpuidle/state0/power: 4294967295
> > > /sys/devices/system/cpu/cpu0/cpuidle/state0/time: 457
> > > /sys/devices/system/cpu/cpu0/cpuidle/state0/usage: 59
> > > /sys/devices/system/cpu/cpu0/cpuidle/state1/desc: ACPI FFH INTEL MWAIT 0x0
> > > /sys/devices/system/cpu/cpu0/cpuidle/state1/latency: 1
> > > /sys/devices/system/cpu/cpu0/cpuidle/state1/name: C1
> > > /sys/devices/system/cpu/cpu0/cpuidle/state1/power: 1000
> > > /sys/devices/system/cpu/cpu0/cpuidle/state1/time: 308177
> > > /sys/devices/system/cpu/cpu0/cpuidle/state1/usage: 3975
> > > /sys/devices/system/cpu/cpu0/cpuidle/state2/desc: ACPI FFH INTEL MWAIT 0x10
> > > /sys/devices/system/cpu/cpu0/cpuidle/state2/latency: 17
> > > /sys/devices/system/cpu/cpu0/cpuidle/state2/name: C2
> > > /sys/devices/system/cpu/cpu0/cpuidle/state2/power: 500
> > > /sys/devices/system/cpu/cpu0/cpuidle/state2/time: 873440787
> > > /sys/devices/system/cpu/cpu0/cpuidle/state2/usage: 239038
> > > /sys/devices/system/cpu/cpu0/cpuidle/state3/desc: ACPI FFH INTEL MWAIT 0x20
> > > /sys/devices/system/cpu/cpu0/cpuidle/state3/latency: 17
> > > /sys/devices/system/cpu/cpu0/cpuidle/state3/name: C3
> > > /sys/devices/system/cpu/cpu0/cpuidle/state3/power: 350
> > > /sys/devices/system/cpu/cpu0/cpuidle/state3/time: 0
> > > /sys/devices/system/cpu/cpu0/cpuidle/state3/usage: 0
> > >
> > > This may be a complete red herring, but I added some printk logic to
> > > acpi_idle_bm_check(), and it is getting called often, but bm_status is
> > > always 1. [I infer from this that the idle logic is trying to go into
> > > C3, but this check is stopping it... Unless I misread something.]
> > >
> > > Is this expected behavior or is this a legitimate problem?
> > >
> > > How might I investigate this further?
> > >
> > > Attaching dmesg, /proc/cpuinfo, powertop -d output.
> > >
> > > Thanks,
> > > Jeff Garrett
> >
> >
> > --
> > peng huang <[email protected]>
> >

--
peng huang <[email protected]>

2010-02-01 14:10:49

by Pavel Machek

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue 2010-01-26 02:47:40, Jeff Garrett wrote:
> Hi,
>
> I was trying to chase down a theory that my desktop machine (a core i7)
> is running warm (the fan sounds like it's at full speed all the time,
> and I think it's not always acted this way -- hence the theory).
>
> powertop is never showing it spending any time in C3...
>
> I compiled a kernel without USB/sound/radeon, and ran without X. I was
> able to get the wakeups/sec down below 20, but no time is spent in C3.

> This may be a complete red herring, but I added some printk logic to
> acpi_idle_bm_check(), and it is getting called often, but bm_status is
> always 1. [I infer from this that the idle logic is trying to go into
> C3, but this check is stopping it... Unless I misread something.]
>
> Is this expected behavior or is this a legitimate problem?
>
> How might I investigate this further?

DMA keeps system awake? Possibly USB?

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2010-02-05 16:09:16

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, Jan 26, 2010 at 10:45:20PM +0100, Andi Kleen wrote:
> [email protected] (Jeff Garrett) writes:
>
> > Hi,
> >
> > I was trying to chase down a theory that my desktop machine (a core i7)
> > is running warm (the fan sounds like it's at full speed all the time,
> > and I think it's not always acted this way -- hence the theory).
> >
> > powertop is never showing it spending any time in C3...
> >
> > I compiled a kernel without USB/sound/radeon, and ran without X. I was
> > able to get the wakeups/sec down below 20, but no time is spent in C3.
>
> [...]
> > This may be a complete red herring, but I added some printk logic to
> > acpi_idle_bm_check(), and it is getting called often, but bm_status is
> > always 1. [I infer from this that the idle logic is trying to go into
> > C3, but this check is stopping it... Unless I misread something.]
>
> Normally a Core i7 (or any modern Intel systems) should not use
> bm_check at all. That's only for older systems that didn't support
> MWAIT with c-state hint, but relied on the old port based interface.

bm_check = 1, bm_control = 0

I don't know what any of this means. :)

I tried changing processor_idle.c. It reads (for C3):
1106 state->enter = pr->flags.bm_check ?
1107 acpi_idle_enter_bm :
1108 acpi_idle_enter_simple;

So it always calls acpi_idle_enter_bm in my case. I tried modifying it
to call acpi_idle_enter_simple for entering C3 instead. When I did
this, it did make it into C3 according to powertop, but the wakeups per
second grew by at least 10x. I couldn't get that below ~400-800/s, and
the residency in C3 was limited to about ~50%, as reported by powertop.

> So something is already confused there.

Might just be me. :)

> I think it should still work though.
> Of course if you really have a lot of bus mastering in the background
> then yes there will be no C3.
>
> -Andi

I have no idea what counts as bus mastering (is it just DMA transfers to
PCI devices?)... But with a fairly idle system, with things like USB
configured out, what could be doing it if it exists? Would there be
some nice function I could instrument with a few printk's to, to see? I
compiled with PCI_DEBUG=y, and "bus master" doesn't show up in the
dmesg.

-Jeff

2010-02-05 16:22:27

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Wed, Jan 27, 2010 at 10:27:17PM +0900, peng huang wrote:
> 2010-01-26 (火) の 08:59 -0600 に Jeff Garrett さんは書きました:
> > On Tue, Jan 26, 2010 at 09:41:00PM +0900, peng huang wrote:
> > > Hi,
> > > can you show me the file /proc/acpi/processor/CPU*/power.
> > > and are you sure your cpu usage is 0 or nearly zero.
> >
> > Yea, I'm pretty sure my cpu usage is nearly zero. powertop shows fewer
> > than 20 wakeups per second, shows 99% C2 residency, top shows 100% idle,
> > perf top shows acpi_idle_enter_simple as the most common function
> > (~50%). Very little is running on the box, and I've compiled out the
> > heavier parts of the kernel (such as USB)...
> >
> > (It still has ordinary userspace running, e.g. udev & hal, and still has
> > sshd and network traffic, as examples.)
> >
> > This is all consistent with a very idle machine, I think.
>
> yes,you processor is always in c2,it does means your system is nearly
> ilde.
>
> > > this is the info of my laptop(using core 2 processors):
> > > powertop's output:
> > > Cn Avg residency P-states (frequencies)
> > > C0 (cpu running) (10.6%) 2.00 Ghz 1.9%
> > > C0 0.0ms ( 0.0%) 1.67 Ghz 0.1%
> > > C1 mwait 0.0ms ( 0.0%) 1333 Mhz 0.0%
> > > C2 mwait 0.0ms ( 0.0%) 1000 Mhz 98.0%
> > > C3 mwait 1.1ms (89.4%)
> >
> > Yea, my laptop also (also core 2) has 700-1000 wakeups/sec and spends
> > greater than 80% of its time in C3... That's partly why I'm curious
> > about what my core i7 desktop is doing.
>
> So I think it is a core i7 thing.I have heard that some intel cpu have a
> problem when in c2-state,maybe that is why you cpu cant enter c3-state.
> I think there is some configuration about deep c-state in the bios,may
> be you can try it(it cannot solve this problem...).

My BIOS has very few options. Almost nothing with regard to
power management. They do let me choose whether to enable
Intel SpeedStep. They also let me choose which state to use
for ACPI suspend (set to S3) but that appears to be it.

> And in some bios there is a enhanced idle state configuration ,but i
> dont known if it is the reason why the cpu cannot enter c3-state.You can
> try it anyway.

I would if I could. :)

> With disable the deep c-state you BIOS will not give c3-info to the
> OS,then you would see there is no c3-state in the OS.

I also found a thread (I think LKML) which said the max c-state is
limited when HT is disabled. I had HT disabled in the BIOS.

Re-enabling HT in the BIOS (with CONFIG_X86_HT=y) doesn't
appear to make any difference.

Thanks,
Jeff

2010-02-05 16:30:40

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Mon, Feb 01, 2010 at 03:10:38PM +0100, Pavel Machek wrote:
> On Tue 2010-01-26 02:47:40, Jeff Garrett wrote:
> > Hi,
> >
> > I was trying to chase down a theory that my desktop machine (a core i7)
> > is running warm (the fan sounds like it's at full speed all the time,
> > and I think it's not always acted this way -- hence the theory).
> >
> > powertop is never showing it spending any time in C3...
> >
> > I compiled a kernel without USB/sound/radeon, and ran without X. I was
> > able to get the wakeups/sec down below 20, but no time is spent in C3.
>
> > This may be a complete red herring, but I added some printk logic to
> > acpi_idle_bm_check(), and it is getting called often, but bm_status is
> > always 1. [I infer from this that the idle logic is trying to go into
> > C3, but this check is stopping it... Unless I misread something.]
> >
> > Is this expected behavior or is this a legitimate problem?
> >
> > How might I investigate this further?
>
> DMA keeps system awake? Possibly USB?

X is not running. USB is not enabled at all (CONFIG_USB_SUPPORT is not
set), and likewise for sound & drm. What could be doing the DMA? :)

If there is DMA, it could be disk or network related. However, I
find it hard to believe that this activity is so constant on a nearly
idle system... Of course, I haven't thought of a way to test this yet.

Attaching my config & dmesg of my latest try.

Thanks,
-Jeff

Attachments:

(No filename) (1.40 kB)
config (78.21 kB)
dmesg (60.05 kB)
Download all attachments

2010-02-05 17:45:42

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

Jeff,
What do you see if you apply just the patch below?

Also, in addition to "powertop -d" to show what the kernel requests,
please run turbostat to show what the hardware actually did:

http://userweb.kernel.org/~lenb/acpi/utils/pmtools-latest/turbostat/turbostat.c

eg.
# turbostat -d -v sleep 5

thanks,
-Len Brown, Intel Open Source Technology Center
---

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 7c0441f..f528625 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -763,7 +763,7 @@ static const struct file_operations acpi_processor_power_fops = {
static int acpi_idle_bm_check(void)
{
u32 bm_status = 0;
-
+return bm_status;
acpi_read_bit_register(ACPI_BITREG_BUS_MASTER_STATUS, &bm_status);
if (bm_status)
acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_STATUS, 1);

2010-02-05 20:54:12

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Fri, Feb 05, 2010 at 12:45:21PM -0500, Len Brown wrote:
> Jeff,
> What do you see if you apply just the patch below?
>
> Also, in addition to "powertop -d" to show what the kernel requests,
> please run turbostat to show what the hardware actually did:
>
> http://userweb.kernel.org/~lenb/acpi/utils/pmtools-latest/turbostat/turbostat.c
>
> eg.
> # turbostat -d -v sleep 5
>
> thanks,
> -Len Brown, Intel Open Source Technology Center

With the patch, powertop reports good C3 residency and wakeups
remain very low. Seems to work. :)

I attached the powertop & turbostat output with this patch.

However, this confuses me. In a previous experiment in the
acpi_processor_setup_cpuidle() function, I replaced the pointer
to acpi_idle_enter_bm() with a pointer to
acpi_idle_enter_simple() even when bm_check is nonzero. With
that, I was able to get into C3, but the wakeups ballooned. But
the difference between what I did, and what you did, is the
difference between acpi_idle_enter_bm() with acpi_idle_bm_check()
returning zero and acpi_idle_enter_simple(). Those code paths
look almost identical. The bm path calls acpi_unlazy_tlb(), and
doesn't appear to call the ACPI_FLUSH_CPU_CACHE(), and they call
sched_clock_idle_sleep_event() in different places. I don't
understand why any of these differences would have had any
significant effect on wakeups.

I'm left wondering if it's a problem on my part. I should repeat
that previous experiment and see if there really is something
significantly different there.

BTW, getting a bit off topic, but since the two code paths are
almost identical, is there any reason not to unite them?
Something like the attached patch might work?

Thanks,
Jeff

Attachments:

(No filename) (1.67 kB)
powertop.out (1.79 kB)
turbostat.out (1.06 kB)
patch (4.63 kB)
Download all attachments

2010-04-27 03:21:55

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Fri, 05 Feb 2010 12:45:21 -0500 (EST)
Len Brown <[email protected]> wrote:

> Jeff,
> What do you see if you apply just the patch below?
>
> Also, in addition to "powertop -d" to show what the kernel requests,
> please run turbostat to show what the hardware actually did:
>
> http://userweb.kernel.org/~lenb/acpi/utils/pmtools-latest/turbostat/turbostat.c
>
> eg.
> # turbostat -d -v sleep 5
>
> thanks,
> -Len Brown, Intel Open Source Technology Center
> ---

To resurrect this thread...

I have a giga-byte GA-P55M-UD4 motherboard and I have this same problem
as well. Len's patch "works" in that I see C6 being used, but it also
cripples the system - if I do a make -j16 kernel build, I see most jobs
serialized onto one or two cores. Without the patch, I see the
full utilization of all 8 hyper-threads as expected.

Now, gigabyte have already b0rked these boards up by using the UHCI
controllers on the PCH instead of the rate matching hubs. Maybe that's
directly the cause of BM activity - maybe they screwed something else
up - is it possible for BIOS/ACPI mistakes to lead to this behaviour?

Jeff - is your board gigabyte too?

--phil

> diff --git a/drivers/acpi/processor_idle.c
> b/drivers/acpi/processor_idle.c index 7c0441f..f528625 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -763,7 +763,7 @@ static const struct file_operations
> acpi_processor_power_fops = { static int acpi_idle_bm_check(void)
> {
> u32 bm_status = 0;
> -
> +return bm_status;
> acpi_read_bit_register(ACPI_BITREG_BUS_MASTER_STATUS,
> &bm_status); if (bm_status)
> acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_STATUS,
> 1);
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>

--phil

2010-04-27 07:26:54

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Mon, 26 Apr 2010, Philip Langdale wrote:

> On Fri, 05 Feb 2010 12:45:21 -0500 (EST)
> Len Brown <[email protected]> wrote:
>
> > Jeff,
> > What do you see if you apply just the patch below?
> >
> > Also, in addition to "powertop -d" to show what the kernel requests,
> > please run turbostat to show what the hardware actually did:
> >
> > http://userweb.kernel.org/~lenb/acpi/utils/pmtools-latest/turbostat/turbostat.c
> >
> > eg.
> > # turbostat -d -v sleep 5
> >
> > thanks,
> > -Len Brown, Intel Open Source Technology Center
> > ---
>
> To resurrect this thread...
>
> I have a giga-byte GA-P55M-UD4 motherboard and I have this same problem
> as well. Len's patch "works" in that I see C6 being used, but it also
> cripples the system - if I do a make -j16 kernel build, I see most jobs
> serialized onto one or two cores. Without the patch, I see the
> full utilization of all 8 hyper-threads as expected.

Curious failure.
I could imagine that there is something in the design of this board
where we want to not enter a deep C-state, and thus the board and
Linux are doing the right thing by avoiding the C-state.
However, ignoring the bm-status check and blindly going to that state
I would expect to impact throughput and latency, but don't see
how that might 'serialize' the workload or otherwise cause it
to use some cores and not others.

It is possible that we jump into those deep states just to be
immediately forced to jump right back out. You'd see this in
high usage counts under /sys/devices/system/cpu/cpu*/cpuidle

turbostat, of course, would tell you the actual residency in those states.
Of course there is a twist... The hardware has a feature to recognize
thrashing and may demote an OS request for a deep state into
an actual hardware request for a shallower state. this is one reason
that the output of powertop (request) and turbostat (result)
may be different.

cheers,
-Len

> Now, gigabyte have already b0rked these boards up by using the UHCI
> controllers on the PCH instead of the rate matching hubs. Maybe that's
> directly the cause of BM activity - maybe they screwed something else
> up - is it possible for BIOS/ACPI mistakes to lead to this behaviour?
>
> Jeff - is your board gigabyte too?
>
> --phil
>
> > diff --git a/drivers/acpi/processor_idle.c
> > b/drivers/acpi/processor_idle.c index 7c0441f..f528625 100644
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -763,7 +763,7 @@ static const struct file_operations
> > acpi_processor_power_fops = { static int acpi_idle_bm_check(void)
> > {
> > u32 bm_status = 0;
> > -
> > +return bm_status;
> > acpi_read_bit_register(ACPI_BITREG_BUS_MASTER_STATUS,
> > &bm_status); if (bm_status)
> > acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_STATUS,
> > 1);
> >

2010-04-27 13:14:14

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Mon, Apr 26, 2010 at 07:40:02PM -0700, Philip Langdale wrote:
> On Fri, 05 Feb 2010 12:45:21 -0500 (EST)
> Len Brown <[email protected]> wrote:
> > Jeff,
> > What do you see if you apply just the patch below?
> >
> > Also, in addition to "powertop -d" to show what the kernel requests,
> > please run turbostat to show what the hardware actually did:
> >
> > http://userweb.kernel.org/~lenb/acpi/utils/pmtools-latest/turbostat/turbostat.c
> >
> > eg.
> > # turbostat -d -v sleep 5
> >
> > thanks,
> > -Len Brown, Intel Open Source Technology Center
> > ---
>
> To resurrect this thread...
>
> I have a giga-byte GA-P55M-UD4 motherboard and I have this same problem
> as well. Len's patch "works" in that I see C6 being used, but it also
> cripples the system - if I do a make -j16 kernel build, I see most jobs
> serialized onto one or two cores. Without the patch, I see the
> full utilization of all 8 hyper-threads as expected.
>
> Now, gigabyte have already b0rked these boards up by using the UHCI
> controllers on the PCH instead of the rate matching hubs. Maybe that's
> directly the cause of BM activity - maybe they screwed something else
> up - is it possible for BIOS/ACPI mistakes to lead to this behaviour?
>
> Jeff - is your board gigabyte too?
>
> --phil

My board identifies it as a Dell. No idea if they rebranded a gigabyte.

The patch seems to work for me as well, powertop shows 97.5% c3,
turbostat shows 93.6% c6 now. I do get weird latency spikes (on I/O)
from time to time.

When I was investigating, I completely configured USB off, and it still
wouldn't go into deep sleep. Not sure how well that meshes with your
UHCI theory.

-Jeff

2010-04-27 15:41:45

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, 27 Apr 2010 03:26:34 -0400 (EDT)
Len Brown <[email protected]> wrote:

>
>
> Curious failure.
> I could imagine that there is something in the design of this board
> where we want to not enter a deep C-state, and thus the board and
> Linux are doing the right thing by avoiding the C-state.
> However, ignoring the bm-status check and blindly going to that state
> I would expect to impact throughput and latency, but don't see
> how that might 'serialize' the workload or otherwise cause it
> to use some cores and not others.

Hmm - and now I can't reproduce it. I got proper parallelization across
the kernel compile. I guess some sort of runtime state was messed up,
and I obviously lost that then I rebooted. :-/

> It is possible that we jump into those deep states just to be
> immediately forced to jump right back out. You'd see this in
> high usage counts under /sys/devices/system/cpu/cpu*/cpuidle
>
> turbostat, of course, would tell you the actual residency in those
> states. Of course there is a twist... The hardware has a feature to
> recognize thrashing and may demote an OS request for a deep state into
> an actual hardware request for a shallower state. this is one reason
> that the output of powertop (request) and turbostat (result)
> may be different.

Without the patch, Turbostat showed C3 residency of 99% for most
hyper-threads with one or two getting ~15% C6 residency. PC3 was 75%.
Cores were at their lowest P state.

With the patch, C6 residency is 99%, PC6 is 75% and 7 hyper-threads at
lowest P state with one stubborning running at a higher level.

I have a very similarly configured machine with an asus motherboard and
it doesn't have this problem - which is another reason I'm wondering if
it's an OEM screwup.

--phil

2010-04-30 16:52:23

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, 27 Apr 2010 07:47:03 -0500
[email protected] (Jeff Garrett) wrote:

> My board identifies it as a Dell. No idea if they rebranded a
> gigabyte.
>
> The patch seems to work for me as well, powertop shows 97.5% c3,
> turbostat shows 93.6% c6 now. I do get weird latency spikes (on I/O)
> from time to time.
>
> When I was investigating, I completely configured USB off, and it
> still wouldn't go into deep sleep. Not sure how well that meshes
> with your UHCI theory.

Does your board expose UHCI controllers or just EHCI with the rate
matching hubs? When you say 'configured USB off'?, do you mean off
in the BIOS or just no drivers?

--phil

2010-04-30 17:30:37

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

Philip, Jeff,
Please open up a bugzilla.kernel.org report and attach the output from
acpidump from your machines.

I am hopeful that the "right thin to do" is to not look at bm-status
and that perhaps there is a bug where we are looking at it
"by mistake".

However, it is important that the system be operating properly
when it indeed using c6 as it does with that 1 line patch
earlier in this thread. So if that patch causes abnormal
operation, please let me know.

thanks,
Len Brown, Intel Open Source Technology Center

2010-04-30 17:45:27

by Matthew Garrett

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Fri, Apr 30, 2010 at 12:25:44PM -0400, Len Brown wrote:

> I am hopeful that the "right thin to do" is to not look at bm-status
> and that perhaps there is a bug where we are looking at it
> "by mistake".

https://patchwork.kernel.org/patch/58962/ - it seems to be a win.

--
Matthew Garrett | [email protected]

2010-04-30 18:36:38

[permalink] [raw]

Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Fri, 30 Apr 2010 18:44:47 +0100, Matthew Garrett <[email protected]>
wrote:
> On Fri, Apr 30, 2010 at 12:25:44PM -0400, Len Brown wrote:
>
>> I am hopeful that the "right thin to do" is to not look at bm-status
>> and that perhaps there is a bug where we are looking at it
>> "by mistake".
>
> https://patchwork.kernel.org/patch/58962/ - it seems to be a win.

Indeed. This patch does solve the C6 problem. I'm not in a position to
speak about whether there's any undesirable I/O latency, but it
passes the basic sanity check.

I have filed https://bugzilla.kernel.org/show_bug.cgi?id=15886 with
my acpi dump - assuming that's still useful.

--phil

2010-07-22 05:35:06