Bug 519116 - powertop report C4 mwait residency abnormally when using tsc as current_clocksource
Summary: powertop report C4 mwait residency abnormally when using tsc as current_clock...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-25 08:50 UTC by Zhang Kexin
Modified: 2010-11-11 16:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-11 16:05:00 UTC


Attachments (Terms of Use)

Description Zhang Kexin 2009-08-25 08:50:05 UTC
Description of problem:
on rhts penryn machine intel-d3c69-01.rhts.bos.redhat.com, when set tsc as the current_clocksource, powertop report C4 mwait residency abnormally.

Version-Release number of selected component (if applicable):
powertop version 1.11

How reproducible:
always

Steps to Reproduce:
1. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource
2. yum -y install powertop
3. powertop -d -t 10
  
Actual results:

[root@intel-d3c69-01 ~]# powertop -d -t 10
PowerTOP 1.11   (C) 2007, 2008 Intel Corporation 

Collecting data for 10 seconds 



Cn	          Avg residency
C0 (cpu running)        ( 0.0%)
polling		  0.0ms ( 0.0%)
C1 mwait	  0.0ms ( 0.0%)
C2 mwait	  0.1ms ( 0.1%)
C4 mwait	 24.5ms (28441.8%) <<---------------------------here is abnormal
P-states (frequencies)
  2.84 Ghz     3.4%
  2.34 Ghz     0.0%
  2.01 Ghz    96.6%
Wakeups-from-idle per second : 11599.8	interval: 0.5s
no ACPI power usage estimate available
Top causes for wakeups:
  39.4% (  inf)       <interrupt> : hpet4 
  17.6% (  inf)       <interrupt> : hpet3 
  17.1% (  inf)       <interrupt> : eth0 
  16.7% (  inf)       <interrupt> : uhci_hcd:usb4, eth1 
   5.5% (  inf)       <interrupt> : hpet2 
   3.1% (  inf)       <interrupt> : hpet5 
   0.3% (  inf)     <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 
   0.1% (  inf)     <kernel core> : hrtimer_start (tick_sched_timer) 
   0.0% (  inf)       <interrupt> : firewire_ohci, HDA Intel 
   0.0% (  inf)     <kernel core> : mod_timer (tcp_delack_timer) 
   0.0% (  inf)              ntpd : hrtimer_start_range_ns (hrtimer_wakeup) 
   0.0% (  inf)              sshd : mod_timer (tcp_write_timer) 
   0.0% (  inf)    NetworkManager : mod_timer (dev_watchdog) 
   0.0% (  inf)    NetworkManager : mod_timer (e100_watchdog) 

Suggestion: increase the VM dirty writeback time from 4.99 to 15 seconds with:
  echo 1500 > /proc/sys/vm/dirty_writeback_centisecs 
This wakes the disk up less frequently for background VM activity

Suggestion: Enable SATA ALPM link power management via: 
  echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
or press the S key.

Recent USB suspend statistics
Active  Device name
  0.0%	USB device usb8 : UHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 uhci_hcd)
  0.0%	USB device usb7 : UHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 uhci_hcd)
  0.0%	USB device usb6 : UHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 uhci_hcd)
  0.0%	USB device usb5 : UHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 uhci_hcd)
  0.0%	USB device usb4 : UHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 uhci_hcd)
  0.0%	USB device usb3 : UHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 uhci_hcd)
  0.0%	USB device usb2 : EHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 ehci_hcd)
  0.0%	USB device usb1 : EHCI Host Controller (Linux 2.6.29.4-1.el6.x86_64 ehci_hcd)


Expected results:
residency should not larger than 100%

Additional info:
powertop will not finish automatically when the specified time expired. ie. after the number of seconds specified as parameter of "-t" of powertop command.
you have to press enter to end the command.
further, the system is very slow, it needs several seconds to see the input command appears. 

when set current_clocksource to hpet, then result of powertop seems normal. and system is not slow either.

Comment 2 Zhang Kexin 2009-08-25 09:08:58 UTC
since kernel is abnormally slow, cc'ed kernel developers to let them decide which component this bug belong to.

Comment 3 RHEL Product and Program Management 2009-08-25 09:15:44 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 4 Phil Knirsch 2009-09-22 09:37:02 UTC
Is the machine still available for tests? I can't seem to access it anymore to run tests on it.

Thanks & regards, Phil

Comment 6 Phil Knirsch 2009-09-28 09:43:46 UTC
Ok, i've looked at the issue now and it seems to really come from a different problem:

If you currently switch to tsc clocksource the time actually stops ticking on the system completely, so the only changes in time that will happen afterwards then are by ntpd. This can lead to any kind of weird problems with any application and is definitely a kernel issue (if at all, it might be that tsc isn't a clocksource that should be used for penryn systems).

I'm changing the component to kernel therefore, so they can take a look at it and comment on the problems here.

Thanks & regards, Phil

Comment 7 Zhang Kexin 2010-05-20 12:07:39 UTC
tested on snapshot4, tsc disppeared from /sys/devices/system/clocksource/clocksource0/available_clocksource

[root@intel-d3c69-01 ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
hpet acpi_pm 

and this machine does not support nonstop_tsc

[root@intel-d3c69-01 ~]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz
stepping	: 10
cpu MHz		: 2003.000
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
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 mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 5651.78
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

I think this bug does not exist anymore. set it as verified.

Comment 8 releng-rhel@redhat.com 2010-11-11 16:05:00 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.


Note You need to log in before you can comment on or make changes to this bug.