On DTrace envy [LWN.net]

On DTrace envy

Posted Aug 10, 2007 19:08 UTC (Fri) by oak (guest, #2786)
In reply to: On DTrace envy by njs
Parent article: On DTrace envy

> Right now on Linux there is no way to take an app and profile its disk
seeks in the same way that oprofile lets us profile its i-cache misses;

Disk seeks can already be done, just not at the kernel side (what's cached
and what's not). There was a demonstration in GUADEC 2007 about a new
(yet to be released) Valgrind extension which catches both file accesses
(open etc) AND accesses to memory mapped files. As Valgrind is a CPU
simulator, it can catch these. You can then have another tool that maps
these file/mmap accesses to the actual disk geometry. There was also UI
for visualizing this.

(Log in to post comments)

Be careful of the implicit context

Posted Aug 29, 2007 20:18 UTC (Wed) by renox (subscriber, #23785) [Link]

Sorry but 'can be done' is very different from 'can be done usefully' i.e. with DTrace a sysadmin can do the disk profile on a live production system, AFAIK Valgrind cannot do this..

Note that I'm not criticising Valgrind which is a very useful tool, just that the great selling point of DTrace is that it can do systemic tracing on live production system, so sure you can do many things with CPU simulators but it's quite out of topic/context..

Be careful of the implicit context

Posted Mar 6, 2008 20:41 UTC (Thu) by oak (guest, #2786) [Link]

IOgrind has been released a while ago.  Its advantage over live system 
profiling is that the results are deterministic whereas live system 
performance measurements can (according to Meeks) differ as much as 10% 
(on Linux) from run to run.  On a properly designed system, you don't 
(anymore) find that large bottlenecks, they are smaller.

If the bottlenecks are larger, I would assume one could catch them even 
with strace (just strace all applicable processes at the same time).