lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Wed, 30 Nov 2011 12:54:23 +0100 (CET)
From:	"Nicolas Kalkhof" <nkalkhof@....de>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Andi Kleen" <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	deepthi@...ux.vnet.ibm.com
Subject: Re: Too many poll_idle cpu calls in kernel 3.2 rc-series


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

Download attachment "dmesg.log" of type "application/octet-stream" (42789 bytes)

Download attachment ".config" of type "application/octet-stream" (63275 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ