Hi Dan & Chad, I will also love to have a flag, maybe "-w", to instuct "ptime -p" to wait for the attached process terminates. This will extend ptime(1) to be useful when measuring the time spent comes only as an afterthought.
On 10/16/07, Dan Price <dp at eng.sun.com> wrote: > > > [resending: it does not seem to have reached the case log the first > time] > > I am very pleased to sponsor the following case for Chad Mynhier. This > case enhances the ptime(1) utility to provide greater precision and > adds useful features. > > The timer is set for 10/22/2007. > > Note that this is an open case submitted by a community member; please > remember to CC Chad on all correspondence. > > Thanks, > > -dp > > ------- ------- ------- ------- ------- ------- ------- ------- ------- > ptime(1) Improvements > Chad Mynhier <cmynhier at gmail.com> > > SUMMARY > > This fast-track enhances the ptime command to address two existing > RFEs[1,2] requesting higher resolution for reporting (microseconds > or nanoseconds), the option to see the full complement of > microstate > statistics, and the ability to see statistics for a currently > running > process. > > The new options are committed interfaces; this case seeks minor > release binding. > > INTERFACE TABLE > > Interface Stability Binding > ---------------------------------------------------------------- > Output Uncommitted Minor > -m option Committed Minor > -p option Committed Minor > ---------------------------------------------------------------- > > > DETAILS > > Overview > > Currently, the ptime command reports three statistics for a > process, > real (i.e., wall clock) time, user time and system time, where > these > statistics are presented at a millisecond resolution. In > addition, > ptime can only report these statistics for a process started as a > child of the command. It does not provide the ability to look at > these > statistics for an existing process. > > We plan to address these issues as follows: > > 1. We will change the default resolution for the statistics > reported > by ptime to nanoseconds instead of milliseconds. (Note that > this > may break scripts that match any number of digits to the right > of > the decimal point but assume that the resolution is > milliseconds. > But note also that the man page states that the human-readable > output is unstable.) > > 2. We will add a -m option that will generate a report containing > the > full set of microstate statistics. > > 3. We will add a -p <pid> option to allow ptime to attach to a > running > process and print a snapshot of the statistics for that > process. > > EXAMPLE > > This example demonstrates nanosecond-resolution reporting: > > # ./ptime /bin/ls > /dev/null > > real 0.001734904 > user 0.000433082 > sys 0.001190076 > # > > This example demonstrates full microstate reporting: > > # ./ptime -m /bin/ls > /dev/null > > real 0.001680855 > user 0.000430206 > sys 0.001139441 > trap 0.000000949 > tflt 0.000000000 > dflt 0.000000000 > kflt 0.000000000 > lock 0.000000000 > slp 0.000000000 > lat 0.000004242 > stop 0.000007332 > # > > This example demonstrates attaching to an existing process: > > # ./ptime -m -p `pgrep syslogd` > > real 49:06:52.585250745 > user 0.035726760 > sys 0.034103073 > trap 0.000154120 > tflt 0.000000000 > dflt 0.000000000 > kflt 0.000000000 > lock 343:48:03.815831359 > slp 245:34:21.457591100 > lat 0.065530109 > stop 0.000043641 > # > > > REFERENCES > > [1] ptime should report microseconds or nanoseconds instead of just > milliseconds > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234106) > [2] ptime should report resource usage statistics from /proc for running > processes > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4532599) > ------- ------- ------- ------- ------- ------- ------- ------- ------- > > > -- > Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - > blogs.sun.com/dp > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org > -- Just me, Wire ... Blog: <prstat.blogspot.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20071016/783e6415/attachment.html>
