2:29 a.m.
Hi list,
I read that PowerTOP 2.0 was released yesterday, so I decided to give
it a run again. First I saw some discrepancy in the CPU usage reported
by PowerTOP. So I ran "while true; do openssl speed aes -multi 4;
done" to utilize all my 4 CPU cores at 100%. htop displays utilization
4x100% all the time. PowerTOP thinks:
Summary: 0.2 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and
187.1% CPU use
Usage Events/s Category Description
1816 ms/s 0.00 Process openssl speed
aes -multi 4
The usage numbers are clearly bogus.
Then I remembered that I already reported some bugs about the PowerTOP
2.0 beta release I tested in January 2011:
On Thu, Jan 13, 2011 at 9:14 PM, Marti Raudsepp <marti(a)juffo.org> wrote:
First, I also see an empty "Idle stats" screen, as reported
by Ian
Kumlien earlier. Old PowerTOP didn't report idle state statistics
either, but at least it had an explanatory message.
"Idle stats page" is still empty:
Package | CPU 0
| CPU 1
| CPU 2
| CPU 3
Fourth, the "Frequency stats" screen starts up showing good
numbers,
but after the first refresh, all per-core numbers turn bogus. For each
core, the percentages always add up to 1895% !
Still occurs, but now the magic constant is always 1961.1%
Package | CPU 0
Idle 0.0% | Idle 0.6%
800 MHz 0.0% | 800 MHz 0.4%
3.00 GHz 100.0% | 3.00 GHz 1960.1%
1.80 GHz 0.0% | 2.31 GHz 0.0%
2.31 GHz 0.0% |
| CPU 1
| Idle 2.6%
| 800 MHz 0.3%
| 3.00 GHz 1958.1%
| 2.31 GHz 0.0%
|
| CPU 2
| Idle 2.0%
| 800 MHz 0.3%
| 3.00 GHz 1958.8%
| 1.80 GHz 0.0%
| 2.31 GHz 0.0%
| CPU 3
| Idle 1.9%
| 800 MHz 0.2%
| 3.00 GHz 1958.7%
| 1.80 GHz 0.3%
| 2.31 GHz 0.0%
Can anyone remind me why do you do beta releases and why should users
spend their time reporting bugs?
Regards,
Marti
2:56 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On 5/11/2012 9:29 AM, Marti Raudsepp wrote:
Hi list,
I read that PowerTOP 2.0 was released yesterday, so I decided to give
it a run again. First I saw some discrepancy in the CPU usage reported
by PowerTOP. So I ran "while true; do openssl speed aes -multi 4;
done" to utilize all my 4 CPU cores at 100%. htop displays utilization
4x100% all the time. PowerTOP thinks:
Summary: 0.2 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and
187.1% CPU use
Usage Events/s Category Description
1816 ms/s 0.00 Process openssl speed
aes -multi 4
The usage numbers are clearly bogus.
hmm we assumed these gaps would go away with the new perfevent library
(it solved cases we had here at least).
8:05 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On 05/11/2012 09:29 AM, Marti Raudsepp wrote:
Hi list,
I read that PowerTOP 2.0 was released yesterday, so I decided to give
it a run again. First I saw some discrepancy in the CPU usage reported
by PowerTOP. So I ran "while true; do openssl speed aes -multi 4;
done" to utilize all my 4 CPU cores at 100%. htop displays utilization
4x100% all the time. PowerTOP thinks:
Can you please tell me what system,
processors and distro (and version)
you are running?
Also are you running in a VM by chance?
Summary: 0.2 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec
and
187.1% CPU use
Usage Events/s Category Description
1816 ms/s 0.00 Process openssl speed
aes -multi 4
The usage numbers are clearly bogus.
Why do you think theyt
Then I remembered that I already reported some bugs about the
PowerTOP
2.0 beta release I tested in January 2011:
On Thu, Jan 13, 2011 at 9:14 PM, Marti Raudsepp<marti(a)juffo.org> wrote:
> First, I also see an empty "Idle stats" screen, as reported by Ian
> Kumlien earlier. Old PowerTOP didn't report idle state statistics
> either, but at least it had an explanatory message.
"Idle stats page" is still empty:
Package | CPU 0
| CPU 1
| CPU 2
| CPU 3
> Fourth, the "Frequency stats" screen starts up showing good numbers,
> but after the first refresh, all per-core numbers turn bogus. For each
> core, the percentages always add up to 1895% !
Still occurs, but now the magic constant is always 1961.1%
Package | CPU 0
Idle 0.0% | Idle 0.6%
800 MHz 0.0% | 800 MHz 0.4%
3.00 GHz 100.0% | 3.00 GHz 1960.1%
1.80 GHz 0.0% | 2.31 GHz 0.0%
2.31 GHz 0.0% |
| CPU 1
| Idle 2.6%
| 800 MHz 0.3%
| 3.00 GHz 1958.1%
| 2.31 GHz 0.0%
|
| CPU 2
| Idle 2.0%
| 800 MHz 0.3%
| 3.00 GHz 1958.8%
| 1.80 GHz 0.0%
| 2.31 GHz 0.0%
| CPU 3
| Idle 1.9%
| 800 MHz 0.2%
| 3.00 GHz 1958.7%
| 1.80 GHz 0.3%
| 2.31 GHz 0.0%
Can anyone remind me why do you do beta releases and why should users
spend their time reporting bugs?
Your bug was not ignored, it was not seen before
release during our
testing.
I have spent three hours testing this bug using your test case above,
and am not seeing the issue.
So it may very well be there is an hardware corner case I need to track
down. Which is why I asked the above questions.
-Chris
Regards,
Marti
_______________________________________________
PowerTop mailing list
PowerTop(a)lists.01.org
https://lists.01.org/mailman/listinfo/powertop
8:23 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
Am Dienstag 15 Mai 2012, 00:05:20 schrieb Chris Ferron:
> On Thu, Jan 13, 2011 at 9:14 PM, Marti
Raudsepp<marti(a)juffo.org> wrote:
>> First, I also see an empty "Idle stats" screen, as reported by Ian
>> Kumlien earlier. Old PowerTOP didn't report idle state statistics
>> either, but at least it had an explanatory message.
>
> "Idle stats page" is still empty:
> Package | CPU 0
>
> | CPU 1
> | CPU 2
> | CPU 3
>>
>> Fourth, the "Frequency stats" screen starts up showing good numbers,
>> but after the first refresh, all per-core numbers turn bogus. For each
>> core, the percentages always add up to 1895% !
>
> Still occurs, but now the magic constant is always 1961.1%
>
> Package | CPU 0
>
> Idle 0.0% | Idle 0.6%
>
> 800 MHz 0.0% | 800 MHz 0.4%
>
> 3.00 GHz 100.0% | 3.00 GHz 1960.1%
> 1.80 GHz 0.0% | 2.31 GHz 0.0%
> 2.31 GHz 0.0% |
>
> | CPU 1
> |
> | Idle 2.6%
> |
> | 800 MHz 0.3%
> |
> | 3.00 GHz 1958.1%
> | 2.31 GHz 0.0%
> |
> | CPU 2
> |
> | Idle 2.0%
> |
> | 800 MHz 0.3%
> |
> | 3.00 GHz 1958.8%
> | 1.80 GHz 0.0%
> | 2.31 GHz 0.0%
> |
> | CPU 3
> |
> | Idle 1.9%
> |
> | 800 MHz 0.2%
> |
> | 3.00 GHz 1958.7%
> | 1.80 GHz 0.3%
> | 2.31 GHz 0.0%
>
Your bug was not ignored, it was not seen before release during our
testing.
I have spent three hours testing this bug using your test case above,
and am not seeing the issue.
So it may very well be there is an hardware corner case I need to track
down. Which is why I asked the above questions.
The same does happen on my cpu here,
which is an AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
| CPU 1
| Idle 713,8%
| 1000 MHz 1182,6%
| 2,00 GHz 23,9%
| 1,80 GHz 9,5%
And the idlestats are empty for the second core
Package | CPU 0
POLL 0,0% | POLL 0,0% 0,0 ms
C1 79,6% | C1 79,5% 2,7 ms
| CPU 1
|
|
Peter
8:25 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On 5/14/2012 3:23 PM, Peter Hüwe wrote:
And the idlestats are empty for the second core
can we start splitting this report up please
I see two separate items
item 1)
On the summary screen, a multithreaded application does not show the
expected percentage
item 2)
On some AMD machine (need some details I suppose on 64/32 bit for both
kernel and powertop) the per cpu stats are off
they seem to be totally unrelated, so can we treat them as unrelated for
now ?
8:57 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On Tue, May 15, 2012 at 1:25 AM, Arjan van de Ven <arjan(a)linux.intel.com> wrote:
can we start splitting this report up please
I see two separate items
Yes, well, I reported 3. :)
they seem to be totally unrelated, so can we treat them as unrelated
for
now ?
Are you saying I should send up 3 separate emails?
Regards,
Marti
9:11 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On Tue, May 15, 2012 at 1:05 AM, Chris Ferron
<chris.e.ferron(a)linux.intel.com> wrote:
Can you please tell me what system, processors and distro (and
version) you
are running?
Also are you running in a VM by chance?
No VM, physical hardware. Arch Linux (testing repos enabled), kernel
3.3.5, x86_64.
Bug #1 occurs on my desktop (AMD Phenom II X4 965) as well as laptop
(Intel Core i5-560M)
Bugs #2 and #3 only occur on the AMD box.
> Usage Events/s Category
Description
> 1816 ms/s 0.00 Process openssl speed
> The usage numbers are clearly bogus.
Why do you think theyt
Not sure what you meant to ask...
I have spent three hours testing this bug using your test case above,
and am
not seeing the issue.
Yeah, these issues are immediately obvious on my machine.
Regards,
Marti
3:29 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On 05/14/2012 04:11 PM, Marti Raudsepp wrote:
On Tue, May 15, 2012 at 1:05 AM, Chris Ferron
<chris.e.ferron(a)linux.intel.com> wrote:
> Can you please tell me what system, processors and distro (and version) you
> are running?
> Also are you running in a VM by chance?
No VM, physical hardware. Arch Linux (testing repos enabled), kernel
3.3.5, x86_64.
Bug #1 occurs on my desktop (AMD Phenom II X4 965) as well as laptop
(Intel Core i5-560M)
OK, lets start with bug 1. It seem there is a definite issues
with
non-intel processors.
Problem is I am having a hard time getting my hands on a non-intel based
system.
Second part of my thoughts is you are seeing a issues wiht you AMD, but
you Core i5
may look similar but actually i suspect is not incorrect. From you
example for bug 1, I am assumeing by what I am seeing that you took
those numbers from your AMD system.
The reason this is important to define, is there is different code paths
for Intel and non-intel processors, so getting comparable data between
them is important. In other words there are three general areas where is
issue could be happening, and if you are actually seeing the same issue
on both processors then it points to the only 1 point that is shard in
this area.
In regards to your Intel system. You could be seeing more the 100% of
cpus. This is the measurement of the cpus not the package. I don't have
the full data sheet for your CPU, but you may see up to 400% as your
system has 2cores with two threads each. 400% of the cpu = 100% of the
package.
You may also see such number while looking at Frequency and C0 active.
For instance 100% would indicate that you are pegged at the Stamped rate
(which is not the max for an Intel processor). over 100% indicates the
the freq governor is running the processor higher then the stamped rate.
So for instance the stamped rate on my i7 is 3.4GHz, and in turbo mode I
can see the rates at 3.5GHz to 3.8GHz at times. So at ~3.5GHz I would
see 102.5% as C0 active as it's about ~2.2 to 2.5% per bin of 100Hz.
At this point I think for Bug1, this is an issue with the "last_stamp"
not getting zeroed out, and the effective freq measurements. It could be
something as simple as below, but like I said I haven't gotten a AMD
system to work with.
Could you reproduce Bug 1 and send me the data for each Processor, and
if you feel so inclined maybe play with the changes below on you AMD
system.
Thanks
Chris
diff --git a/src/cpu/cpu_linux.cpp b/src/cpu/cpu_linux.cpp
index ab37d57..8aa9772 100644
--- a/src/cpu/cpu_linux.cpp
+++ b/src/cpu/cpu_linux.cpp
@@ -59,6 +59,8 @@ void cpu_linux::measurement_start(void)
abstract_cpu::measurement_start();
+ last_stamp = 0;
+
len = sprintf(filename,
"/sys/devices/system/cpu/cpu%i/cpuidle", number);
dir = opendir(filename);
@@ -365,6 +367,7 @@ void cpu_linux::change_effective_frequency(uint64_t
time, uint64_t frequency)
effective_frequency = frequency;
last_stamp = time;
+ abstract_cpu::change_effective_frequency(time, frequency);
}
7:04 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On Tue, May 15, 2012 at 8:29 PM, Chris Ferron
<chris.e.ferron(a)linux.intel.com> wrote:
OK, lets start with bug 1. It seem there is a definite issues with
non-intel
processors.
Problem is I am having a hard time getting my hands on a non-intel based
system.
Second part of my thoughts is you are seeing a issues wiht you AMD, but you
Core i5
may look similar but actually i suspect is not incorrect.
The reason this is important to define, is there is different code
paths for
Intel and non-intel processors, so getting comparable data between them is
important. In other words there are three general areas where is issue could
be happening, and if you are actually seeing the same issue on both
processors then it points to the only 1 point that is shard in this area.
Well the symptoms are the same on both Intel and AMD. If you say the
code paths are independent then the problem might be something
external -- libraries, kernel, perf, etc. Maybe something specific to
Arch Linux that doesn't occur on your distro?
One thing I noticed is when I manually refresh the screen with the R
key, it always correctly reports ~399% CPU use. Only when I wait it to
refresh by itself, it displays bogus numbers.
Here's the Intel system:
Summary: 0.5 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and
166.4% CPU use
Usage Events/s Category Description
100.0% Device Radio device: dell-laptop
1.8 ms/s 0.00 Process
/usr/bin/pulseaudio --start --log-target=syslog
60.0 pkts/s Device Network
interface: wlan0 (iwlwifi)
100.0% Device USB device:
DW375 Bluetooth Module (Dell Computer Corp)
20.0 µs/s 0.20 kWork flush_to_ldisc
17.6 µs/s 0.10 Process SCREEN -Rd
1621 ms/s 0.05 Process openssl speed
aes -multi 4
Intel, manually refreshed:
Summary: 0.6 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and
397.6% CPU use
Usage Events/s Category Description
100.0% Device Radio device: dell-laptop
7.2 ms/s 0.00 Process
/usr/bin/pulseaudio --start --log-target=syslog
93.6 pkts/s Device Network
interface: wlan0 (iwlwifi)
100.0% Device USB device:
DW375 Bluetooth Module (Dell Computer Corp)
7.6 ms/s 0.6 Process
/usr/lib/firefox/plugin-container /usr/lib/mozilla/plugins/libflas
3724 ms/s 0.00 Process openssl speed
aes -multi 4
AMD system:
Summary: 2.1 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and
186.0% CPU use
Usage Events/s Category Description
1760 ms/s 0.05 Process openssl
100.0% Device Audio codec hwC0D0: VIA
64.0 ms/s 0.05 Process openssl speed
aes -multi 4
AMD, manually refreshed:
Summary: 0.0 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and
399.7% CPU use
Usage Events/s Category Description
3902 ms/s 0.00 Process openssl speed
aes -multi 4
I also tried launching 4 copies of 'dd if=/dev/zero of=/dev/null' to
see if this is specific to openssl, but no -- it also happens with dd.
In regards to your Intel system. You could be seeing more the 100% of
cpus.
This is the measurement of the cpus not the package. I don't have the full
data sheet for your CPU, but you may see up to 400% as your system has
2cores with two threads each.
400% of the cpu = 100% of the package.
Yeah, I'm expecting to see 400% utilization.
Could you reproduce Bug 1 and send me the data for each Processor,
and if
you feel so inclined maybe play with the changes below on you AMD system.
/proc/cpuinfo:
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 940 Processor
stepping : 2
microcode : 0x1000086
cpu MHz : 800.000
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit
wdt npt lbrv svm_lock nrip_save
bogomips : 6028.35
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
----
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz
stepping : 5
microcode : 0x2
cpu MHz : 1199.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
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 rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt aes
lahf_lm ida arat dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 5322.27
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Any other info I can provide?
At this point I think for Bug1, this is an issue with the
"last_stamp" not
getting zeroed out, and the effective freq measurements. It could be
something as simple as below, but like I said I haven't gotten a AMD system
to work with.
Thanks, I tried your patch, but the issue remains.
PS: If you haven't set up your mail client to preserve tabs/long lines
then please send the patch as an attachment instead of pasting.
Regards,
Marti
2:37 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On Tue, May 15, 2012 at 8:29 PM, Chris Ferron
<chris.e.ferron(a)linux.intel.com> wrote:
> OK, lets start with bug 1. It seem there is a definite issues with non-intel
> processors.
On Thu, May 17, 2012 at 12:04 AM, Marti Raudsepp <marti(a)juffo.org> wrote:
Any other info I can provide?
Ping? Any updates on this?
Regards,
Marti
5:58 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On 06/01/2012 09:37 AM, Marti Raudsepp wrote:
> On Tue, May 15, 2012 at 8:29 PM, Chris
Ferron<chris.e.ferron(a)linux.intel.com> wrote:
>> OK, lets start with bug 1. It seem there is a definite issues with non-intel
>> processors.
On Thu, May 17, 2012 at 12:04 AM, Marti Raudsepp<marti(a)juffo.org> wrote:
> Any other info I can provide?
Ping? Any updates on this?
I didn't forget about the problem, but like I stated
in previously I
didn't have access to non Intel hardware. I have ordered a non-intel
laptop specificity to work on this issue, but until I get hardware this
issue will have to sit on the back burner. I should have the system soon.
-Chris
Regards,
Marti
6:05 a.m.
New subject: [Powertop] PowerTOP 2.0 bugs
On Fri, Jun 1, 2012 at 10:58 PM, Chris Ferron
<chris.e.ferron(a)linux.intel.com> wrote:
I didn't forget about the problem, but like I stated in
previously I didn't
have access to non Intel hardware.
As I demonstrated, I can reproduce the problem on my Intel laptop and
also an Intel server. I don't know why you're having trouble
reproducing it, but the CPU vendor is not the problem.
Regards,
Marti
3761
days inactive
3782
days old
11 comments
4 participants
participants (4)
-
Arjan van de Ven -
Chris Ferron -
Marti Raudsepp -
Peter Hüwe