On 9/29/07, Peter Tribble <peter.tribble at gmail.com> wrote: > On 9/29/07, Chad Mynhier <cmynhier at gmail.com> wrote: > > > > What should the semantics of "ptime -p <pid> be? I see two options: > > - ptime should report usage after the specified process has finished. > > - ptime should report statistics for the process up to that point > > (i.e., ptime returns almost immediately.) > > For the first one I think it's actually when ptime finishes - whether that's > because the process exits or you ctrl-C out of ptime. > > I think there are two questions that could be asked of a process: > > - what have you used so far? (your second option) > > - at what rate are you currently accumulating all the statistics? > > I'm not exactly how best to give the user the information in > my second case. It could, after all, be emulated by running > ptime repeatedly against the process and calculating the > differences. Would something like adding an interval and count > like some of the other stat utilities and getting it to print out > the rates work?
This would certainly be easy enough to implement, but I don't know that ptime is the right place to do it. You already get this information (at least to some resolution) from "prstat -m -p <pid>" . The only difference in doing it with ptime is that you would get that information in milliseconds (or microseconds or nanoseconds[1]) rather than as a percentage of the sample period. Are there cases where the better resolution matter? And if so, would it be better to improve the resolution in prstat? (Admittedly difficult without stretching prstat output out well past 100 columns.) (And arguably, this discussion is tangential to the "-p" issue, as reporting these stats at intervals would also apply to running a command diirectly under pstat.) (And as another tangent, formatting for this gets ugly, especially at nanosecond resolution for all of the microstate accounting stats, e.g.: > ptime -nm -p 12168 real 26:13.183980889 user 25:25.147288476 sys 1.604487196 trap 0.545166805 tflt 0.000000000 dflt 0.000166502 kflt 0.000000000 lock 0.000000000 slp 0.016519853 lat 45.870138683 stop 0.000010124 > That's some 200-odd columns worth of output if done in the regular *stat fashion. Post-processing of the output is almost necessary to get anything useful, at which point it might be easier to have the post-processing script just loop over calls to ptime.) Chad [1] Shameless plug for my sponsor request for the ptime microsecond/nanosecond patch: http://www.opensolaris.org/jive/thread.jspa?threadID=40366&tstart=0.
