Hi Krishnendu, Thank you for these excellent suggestions, I think they will improve the usability of LatencyTOP.
For the adaptive-block probe, it is possible to add it to the D script, but when it happens, the sleep time will be counted by both adaptive-block and the off-cpu/on-cpu probes in LatencyTOP. If the value from adaptive-block is then put in the same list as "normal" data, the result will be duplicate. I think if this probe is to be added, it is better to place this data, possibly along with other data added in the future, somewhere that user can easily see the difference. Do you have any suggestion? > Thanks Eric for your thoughts. In order to answer > these questions better, I am wondering whether the > tool should make use of another dtrace probe : > > adaptive-block -> this tells us how much time > the thread is sleeping on an adaptive lock > > > Also, I have some suggestions regarding the > look-and-feel of the tool : > > i) I am wondering whether it will be more > user-friendly if the user can use the left arrow > (<|--) and the right-arrow (--|>) keys for > navigating the list of processes, instead of using > the < and > keys. I personally feel more comfortable > using the arrow keys for navigating a long list of > processes. > iii) Currently, modifying the translation table > requires recompilation. Is there any other way we > can make it a bit easier for the end-user ? For > example, is it possible to have a file under /etc > which will be read by latencyTOP when it starts ? If > the user modifies this configuration file, either > restarting latencyTOP or pressing a hot key (to > force latencyTOP to re-read the configuration file > on the fly and adapt the output accordingly) will > make the new changes take effect. The user may not > have the source code and compilation environment > handy all the time, so this can make her job > easier. > iv) I am thinking that we can probably make the log > file format a little better and more readable. For > example, now the log looks like this : > > ------------------------------------------------------ > ------------------------------------------------------ > -------------- > # Log generated Tue Jul 4 07:14:07 2000 by > LatencyTOP for OpenSolaris, version > 0.1 > # PID CMD > # 3 fsflush > # 100713 /usr/java/bin/java -server -Xmx128m > -XX:+UseParallelGC -XX:ParallelGCTh > reads=4 > # 100572 devfsadmd > total,count,max,pid,kstack > 4915802181,82,59978417,100713,"genunix`cv_timedwait_si > g_internal genunix`cv_wait > until_sig genunix`poll_common genunix`pollsys > unix`sys_syscall32" > 4039698564,4,1009942057,100713,"genunix`lwp_cond_wait > unix`sys_syscall32" > 3999861198,2,1999973479,100572,"genunix`cv_timedwait_s > ig_internal genunix`cv_wai > tuntil_sig genunix`lwp_park genunix`syslwp_park > unix`sys_syscall32" > ------------------------------------------------------ > ------------------------------------------------------ > -------------- > > I was wondering whether the following format is a > better choice (it seems more readable): > > # Log generated Tue Jul 4 07:14:07 2000 by > LatencyTOP for OpenSolaris, version > 0.1 > <------ > *PUT A SPACE* > PID CMD > <----- *SEPARATE THE > COLUMNS A BIT MORE AND ALIGN THEIR ENTRIES** > *3 fsflush > 100713 /usr/java/bin/java -server -Xmx128m > -XX:+UseParallelGC -XX:ParallelGCThreads=4 > 100572 devfsadmd > > ----- *PUT A SPACE* > TOTAL, COUNT, MAX, PID, KSTACK <----- *CAPITALIZE > THE HEADERS AND SEPARATE THEM BY ONE SPACE* > 4915802181, 82, 59978417, 100713, > "genunix`cv_timedwait_sig_internal genunix`cv_wait > <---- S*EPARATE THEM BY SPACE* > til_sig genunix`poll_common genunix`pollsys > unix`sys_syscall32" > 4039698564, 4, 1009942057, 100713, > "genunix`lwp_cond_wait unix`sys_syscall32" > 3999861198, 2, 1999973479, 100572, > "genunix`cv_timedwait_sig_internal genunix`cv_wai > tuntil_sig genunix`lwp_park genunix`syslwp_park > unix`sys_syscall32" -- This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
