Krishnendu Sadhukhan wrote: > It has been found during testing that if a process goes to sleep > before LatencyTOP runs, LatencyTOP is unable to track that latency. > The reason being that using DTrace, we probably can't record this > type of latency.
Yes, latencytop relies on off-cpu to be fired first to record the timestamp in thread local variables. > Having such a capability in LatencyTOP might be > useful in cases where an application process (its LWP rather) is > already sleeping and we want to track its latency, without restarting > the application. The information from latencytop is a summary of what is happening in the system. If the problem repeats itself, latencytop will capture it next time it happens. If the problem only happens one time, e.g. at some point the application is not running any more, probably debuggers are more useful than latency*top* in such cases :-) > > I propose that we investigate the possibility of implementing such a > feature in LatencyTOP. Hence I would like to know what others think > about it. > > As for implementing, we can open the LWP directories under /proc and > check the 'pr_flags' member of the lwpstatus_t structure; if an LWP > is sleeping, the 'pr_flags' member will have its PR_ASLEEP bits set. The information about latencies is first collected in dtrace. Although latencytop may know which threads are sleeping upon start, there's no easy way to make dtrace capture these wakeups. > I don't know if there is any other easier and quicker way of > achieving this objective. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
