There is a new -N (unNormalized) option being added by the CPU Caps project which does exactly this. If you want it now, download the source code tarball and compile your own version of prstat.
On 10/19/06, Bob Sneed, SMI PAE <[EMAIL PROTECTED]> wrote:
Richard McDougall wrote: > Hi Bob, > > >> I've often wanted to see prstat changed to consistently show 'percent of >> a CPU core', >> so that values might exceed 100 for multi-threaded apps, and so >> per-process values >> from the same task running on different configurations would be more >> comparable. >> > > Can you expand on the scenarios in which you would use this, an how > the information would be interpreted? > Sure. For me, 'scenarios=all'. :-) On a 72-way system, a single CPU hog shows as 1.4%. On an 8-way system, it will show as 12.5%. Absent the context of the core count, it's not obvious that it's a CPU- bound process, or that it's using the same absolute CPU resource on these two systems. On a (mythical) 250-way system, after rounding to the first decimal, it would show as 0.0%. I'd rather see it reported as using 100% (of a CPU) in all cases, without being personally burdened with the task of dividing by N. When using '-m' without '-L', I'd like to see that hog/6 is using 400% CPU without needing to switch views. With 32 CPU-bound threads on a T1-based system, I *think* I'd like to see each one reported as using 25% (of a core). With CMT, it maybe gets a bit fuzzy? In other words, I think '%systemwide_cpu' is fundamentally annoying, as is seeing 'percent of total' (with -m) without seeing 'total' at the same time. I believe most people would agree. Am I right -- or just annoying? Cheers, -- Bob > Thanks, > > Richard. > > > > >> With '-m', the 'percent of total' concept needs to be maintained, but >> maybe adding >> another column would help. The issue of units extends to the '-T' >> rollups. Some on >> this thread have also wished for more 'top-like' outputs from prstat, >> such as aggregate >> usr/sys/idle. (I can offer free counseling for those who want %wio. ;-) ) >> >> Actually, as we evolve to systems architectures with massive thread >> counts, we'll >> see CPU-bound threads average to 0% with the current implementation. Yikes! >> >> How about '-A' for 'Aggregate' and '-X' for 'eXtended'? I don't want to >> file an RFE >> until there is some consensus on these notions. >> >> Cheers, >> -- Bob >> >>> Regards, >>> >>> Richard. >>> >>> >>> >>> >>> On Thu, Oct 19, 2006 at 08:34:17AM -0700, Cherian Abraham wrote: >>> >>> >>>> Hi All, >>>> >>>> Thanks for all the feedback. >>>> I tried to run both prstat and prstat -m option and here are the output >>>> displays... >>>> (showing only three processes). >>>> >>>> prstat -mL >>>> PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG >>>> PROCESS/LWPID 25952 root 30 30 0.0 0.0 0.0 0.0 30 0.0 100 6K 87K >>>> 0 processC/1 >>>> 25571 root 5.1 0.7 0.0 0.0 0.0 0.0 93 0.0 57 68 5K 0 processB/1 >>>> 2003 root 0.3 1.2 0.1 0.0 0.0 0.0 97 1.9 67 8 1K 21 processA/1 >>>> >>>> prstat >>>> PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP >>>> 2003 root 39M 38M sleep 59 0 3:05:58 0.6% processA/1 >>>> 25571 root 6488K 5752K sleep 13 0 0:00:00 0.5% processB/1 >>>> 25952 root 5208K 4184K sleep 23 0 0:00:00 0.1% processC/1 >>>> >>>> Is it possible to relate the CPU usage shown by prstat and prstat -m ? or >>>> am i comparing apples and oranges here ? process C shows 0.1% CPU usage >>>> (is this only usr time?) and microstate accounting shows 30% user time, >>>> 30% sys time and 30% sleep. How does one relate the two ? The above is >>>> just snapshots taken almost at the same time. >>>> My testing is normally done in a 2 hr time frame. So i could run prstat >>>> with 10 sec sampling rate and prstat -m with also a 10 sec sampling rate >>>> during the same period. The sampling instance for both maybe slightly >>>> off. If i average out during this run for each process from prstat and >>>> also the same from prstat -m, how do i relate these values ? >>>> >>>> >>>> This message posted from opensolaris.org >>>> _______________________________________________ >>>> perf-discuss mailing list >>>> perf-discuss@opensolaris.org >>>> >>>> >>> >>> > > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
