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,

> 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

zones-discuss mailing list

Reply via email to