On Sun, Nov 16, 2008 at 10:58 PM, Mike Gerdts <[EMAIL PROTECTED]> wrote: > On Sun, Nov 16, 2008 at 7:40 PM, Jeff Victor <[EMAIL PROTECTED]> wrote: >> To me, the clearest example would be a kstat, per zone, which provides >> the total amount of CPU time for all of the processes in each zone, >> since the zone booted. This would enable tools like zonestat to >> request the datum occasionally, in order to determine CPU time per >> quantum of elapsed time. > > zonestat shouldn't be needed to give this information.
Of course. I guess I wasn't clear. I was trying to say "the clearest example of a kstat that is needed is a kstat, per zone... That kstat could then be used by many *stat tools, including zonestat, prstat, etc." > Per zone, project, and user data should be available that allows prstat to > display this information. When I use prstat -mz or prstat -ma, I > would expect the collected microstate accounting data would be used to > populate the display. Other fine points about this include: > > - Currently prstat shows time decayed summaries in the bottom panel, even > when microstate data is displayed at the top. Time decayed data > is confusing, particularly when trying to correlate application events that > last just several seconds to CPU consumption. Not only is it confusing, it can be very wrong, e.g. if there are many short-lived processes that come and go between the snapshots that prstat takes. That's why a kstat like the one described above is needed. --JeffV _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
