Re: Too many poll_idle cpu calls in kernel 3.2 rc-series

From: Nicolas Kalkhof
Date: Wed Nov 30 2011 - 06:54:35 EST

Next message: Catalin Marinas: "Re: kmemleak: unreferenced object in copy_thread"
Previous message: Neil Horman: "Re: linux-next: build failure after merge of the final tree (akpmtree related)"
In reply to: Deepthi Dharwar: "Re: Too many poll_idle cpu calls in kernel 3.2 rc-series"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Andi, Hi Deepthi

I'm still in the process of reverting and testing the commits.

I definately have to pass idle=mwait as boot paremeter otherwise powertop looks like below. CONFIG_INTEL_IDLE does not change that.
Strange thing I too have a Lenovo T420 with a I7-2620M.

cat /proc/cpuinfo
processorÂÂÂÂÂÂ : 0
vendor_idÂÂÂÂÂÂ : GenuineIntel
cpu familyÂÂÂÂÂ : 6
modelÂÂÂÂÂÂÂÂÂÂ : 42
model nameÂÂÂÂÂ : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
steppingÂÂÂÂÂÂÂ : 7
microcodeÂÂÂÂÂÂ : 0x1b
cpu MHzÂÂÂÂÂÂÂÂ : 800.000
cache sizeÂÂÂÂÂ : 4096 KB
physical idÂÂÂÂ : 0
siblingsÂÂÂÂÂÂÂ : 2
core idÂÂÂÂÂÂÂÂ : 0
cpu coresÂÂÂÂÂÂ : 2
apicidÂÂÂÂÂÂÂÂÂ : 0
initial apicidÂ : 0
fpuÂÂÂÂÂÂÂÂÂÂÂÂ : yes
fpu_exceptionÂÂ : yes
cpuid levelÂÂÂÂ : 13
wpÂÂÂÂÂÂÂÂÂÂÂÂÂ : yes
flagsÂÂÂÂÂÂÂÂÂÂ : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomipsÂÂÂÂÂÂÂ : 5382.00
clflush sizeÂÂÂ : 64
cache_alignment : 64
address sizesÂÂ : 36 bits physical, 48 bits virtual
power management:

Maybe there is a Problem with my configuration I don't know. Again I've attached my kernel .config.
Dmesg reports a problem when I use poll=mwait:

WARNING: at arch/x86/kernel/process.c:622 idle_setup+0x8f/0xef()
"idle=mwait" will be removed in 2012
Modules linked in:
Pid: 0, comm: swapper Not tainted 3.2.0-rc3-next-20111130 #1
Call Trace:
Â[<ffffffff8102d1d2>] ? warn_slowpath_common+0x78/0x8c
Â[<ffffffff8102d287>] ? warn_slowpath_fmt+0x45/0x4a
Â[<ffffffff81575ff2>] ? idle_setup+0x8f/0xef
Â[<ffffffff815706d7>] ? do_early_param+0x54/0x7d
Â[<ffffffff81040b02>] ? parse_args+0x16a/0x21a
Â[<ffffffff81570683>] ? unknown_bootoption+0x1e2/0x1e2
Â[<ffffffff81570753>] ? parse_early_param+0x31/0x40
Â[<ffffffff815730d9>] ? setup_arch+0x317/0x8f7
Â[<ffffffff813b29b5>] ? printk+0x40/0x4b
Â[<ffffffff815707e5>] ? start_kernel+0x81/0x314
---[ end trace 4eaa2a86a8e2da22 ]---

Using CONFIG_INTEL_IDLE top/htop sometimes shows 100% cpu load on both cores for quite some time however the cpu stays idle at low frequency and temperature. That's why I've disabled INTEL_IDLE.

without passing poll=mwait powertop 1.98 shows:

ÂÂÂÂÂÂÂÂ PackageÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂ CoreÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂ CPU 0
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C0 activeÂ 48.2%
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | POLLÂÂÂÂÂÂ 84.7%ÂÂÂ 1.3 ms
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C1-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms
C2 (pc2)ÂÂÂ 0.0%ÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |
C3 (pc3)ÂÂÂ 0.0%ÂÂÂ | C3 (cc3)ÂÂÂ 0.0%ÂÂÂ | C3-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms
C6 (pc6)ÂÂÂ 0.0%ÂÂÂ | C6 (cc6)ÂÂÂ 0.0%ÂÂÂ | C6-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms
C7 (pc7)ÂÂÂ 0.0%ÂÂÂ | C7 (cc7)ÂÂÂ 0.0%ÂÂÂ | C7-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂ CoreÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂ CPU 1
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C0 activeÂ 48.2%
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | POLLÂÂÂÂÂÂ 89.1%ÂÂÂ 1.4 ms
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C1-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ |
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C3 (cc3)ÂÂÂ 0.0%ÂÂÂ | C3-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C6 (cc6)ÂÂÂ 0.0%ÂÂÂ | C6-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | C7 (cc7)ÂÂÂ 0.0%ÂÂÂ | C7-SNBÂÂÂÂÂ 0.0%ÂÂÂ 0.0 ms

Regards,
Nic

On 11/29/2011 02:14 AM, Andi Kleen wrote:

> On Mon, Nov 28, 2011 at 09:31:13PM +0100, Nicolas Kalkhof wrote:
>> Andi,
>>
>> correct. The issue was introduced somewhere between 3.1 final and 3.2-rc1. I've tried to track down the bad commit but so far I haven't been successfull. The only workaround I found is to set the idle boot parameter to mwait and to disable CONFIG_INTEL_IDLE. Somehow the kernel seems to set idle to poll by default - no idea why :-(. I wonder if other mobile sandy bridge cpus are affected as well.
>
> There are only a few changesets affecting drivers/idle
>
> Can you try to git revert
>
> 46bcfad7a819bd17ac4e831b04405152d59784ab
> 4202735e8ab6ecfb0381631a0d0b58fefe0bd4e2
> e978aa7d7d57d04eb5f88a7507c4fb98577def77
>
> ?
>
> -Andi

Hi,

I am guessing that for workaround just setting the idle boot parameter
to mwait should work. Have u tested this without disabling
CONFIG_INTEL_IDLE ?

Also one thing to note from your logs is, cpu is not entering any of the
other C states except for POLL. Can you also check if your are enabling
only POLL for idle. I am able to enter deeper C-states on i5-2540M with
Intel_Idle enabled.

Power top o/p:
-------------
Core | CPU 0 CPU 1
POLL 0.0% | POLL 0.0% 0.0 ms 0.0% 0.0 ms
C1-SNB 1.4% | C1-SNB 2.2% 0.7 ms 0.5% 0.9 ms
C3-SNB 0.9% | C3-SNB 1.6% 1.2 ms 0.1% 1.2 ms
C6-SNB 0.2% | C6-SNB 0.3% 1.6 ms 0.0% 0.9 ms
C7-SNB 95.8% | C7-SNB 93.7% 3.7 ms 97.8% 15.1 ms

Regards,
Deepthi

___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Attachment: dmesg.log
Description: Binary data

Attachment: .config
Description: Binary data

Next message: Catalin Marinas: "Re: kmemleak: unreferenced object in copy_thread"
Previous message: Neil Horman: "Re: linux-next: build failure after merge of the final tree (akpmtree related)"
In reply to: Deepthi Dharwar: "Re: Too many poll_idle cpu calls in kernel 3.2 rc-series"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]