[Mono-bugs] [Bug 523520] New: processor core performance counters return bad values

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=523520


           Summary: processor core performance counters return bad values
    Classification: Mono
           Product: Mono: Runtime
           Version: 2.4.x
          Platform: x86-64
        OS/Version: SLES 10
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: misc
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: jacob.gladish at sig.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---


Created an attachment (id=306178)
 --> (http://bugzilla.novell.com/attachment.cgi?id=306178)
small test program

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727;
InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152;
NET CLR 3.5.30729)

When sampling each instance of PerformanceCounter in the Processor category,
the values of each counter appear to be off by a fact equal to the number of
processors cores on the machine. 

Reproducible: Always

Steps to Reproduce:
1. Run test app
2. Compare output to top
3.
Actual Results:  
Values reported are not what is reported by top

Expected Results:  
Values should be similar to those of top

This patch seems to work for me.

amsdevbal801# diff mono/utils/mono-proclib.orig.c mono/utils/mono-proclib.c


402d401
<       hz *= mono_cpu_count ();


The _Total counter is missing, and if that is ever implemented, this change
will also make that counter correct as the _Total is typicaly represntative of
the aggregate usage, therefore, can reports values over 100%. My interpretation
of this line of code is that someone put it there to try to normalize the total
jiffies to 100% when compared with 100ns wall clock.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.