On 08/10/10 09:00 AM, Milan Jurik wrote:
Hi Aubrey,
Li, Aubrey píše v út 10. 08. 2010 v 19:50 +0800:
Hi Milan,
This is a powertop bug. Please file a bug against it.
CR 6975879 powertop output hangs under heavy load
and you are in CC of the bug.
Can you help to verify if the attached
binary fixed the problem on your side?
I will push build and verify tonight.
The patch is as follows, if it fixed the problem, can you help to put it back?
If Rafael Vanoni is busy with other things, then I am ready to sponsor
it.
Thank you for reporting it and Aubrey for finding and fixing the issue.
If you have free cycles to sponsor the fix, please feel free to do so.
I'd be happy to code review it.
Rafael
Thank you
Milan
Thanks,
-Aubrey
diff -r 87e07d18c459 usr/src/cmd/powertop/common/powertop.c
--- a/usr/src/cmd/powertop/common/powertop.c Mon Jul 19 19:56:37 2010 -0700
+++ b/usr/src/cmd/powertop/common/powertop.c Tue Aug 10 03:26:26 2010 +0800
@@ -397,7 +397,8 @@
* specified an interval we skip this bit and keep it fixed.
*/
if (g_features& FEATURE_CSTATE&& !PT_ON_TIME&&
- g_longest_cstate> 0) {
+ g_longest_cstate> 0&&
+ g_cstate_info[g_longest_cstate].events> 0) {
double deep_idle_res = (((double)
g_cstate_info[g_longest_cstate].total_time/MICROSEC
/g_ncpus)/g_cstate_info[g_longest_cstate].events);
Hi,
Li, Aubrey píše v po 09. 08. 2010 v 09:09 +0800:
Milan Jurik wrote:
Hi,
during playing with new build 145 I discovered strange thing:
C0 (cpu running) (100.0%) 1000 Mhz
100.0%
C1 0.0ms (0.0%) 1333 Mhz
0.0%
1667 Mhz
0.0%
Also kstat indicates that system is running on 1GHz only. No difference
between poll-mode and default.
Is powertop freezing? did you see the change of Top causes for wakeups?
This is interesting. I did not expect it because other commands were
redrawing but I missed it. When I tried to reproduce it this morning,
for the first time I saw different percentages than 100, 0, 0, and
powertop stops to redraw the values (including top part). Also, in
aprox. one from five cases I run kstat, I see current_clock_Hz going to
the maximum value, for the rest of time it remains on 1GHz - no idea why
because harddisk seems to be inactive and compilation is running. Also
again it does not depend on poll-mode or default.
100% C0 residency indicated the system has 100% cpu utilization.
Yes, I would expect it.
when you used poll-mode, did you set cpu-threshold to 1s in /etc/power.conf?
Yes.
It would be interesting to see how the compilation caused 100% cpu
utilization.
Do you know SFE repo? SFEboost.spec is my test case
I tried to do the nightly, everything works fine. Can you give more details how
to replicate this issue?
What system did you use for replication of the issue? My system has some
memory limits (ZFS, Gnome desktop, 4GB of RAM) and 2 cores and standard
laptop harddisk (but that seems to be not active during build much, it
goes to memory cache).
By the way, we didn't change cpupm related code for a long time, does this
issue
exist on the other build?
I saw it in build 145 the first time, but I did not use previous few
builds for this type of workload. I can look at older builds if
necessary.
Thanks,
-Aubrey
Best regards,
Milan
This combination happen when I run intensive compilations (build of
boost with Sun Studio). And it is very strange even more, typical output
of prstat:
9667 mj162486 66M 62M cpu0 30 0 0:00:06 13%
ccfe/1
9671 mj162486 60M 55M run 21 0 0:00:05 11%
ccfe/1
but top reports:
9643 mj162486 1 31 0 63M 59M run 0:05
46.59%
ccfe
9650 mj162486 1 22 0 48M 44M run 0:02
26.60%
ccfe
Basically I see much smaller values of CPU usage in prstat than in top.
And I am pretty sure that in reality the CPU (Intel C2D in Thinkpad T60)
is very busy (also Gnome applet shows full load).
If I break compilation and do some "normal" work like browsing, powertop
shows some changes in frequency to higher values.
Best regards,
Milan
_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss
_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss
_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss
