“The Intel Open Source Technology Center is pleased to announce the release of version 0.1 of LatencyTOP, a tool for developers to visualize system latencies. Slow servers, skipping audio, jerky video – everyone knows the symptoms of latency. But to know what’s really going on in the system, what’s causing the latency, and how to fix it… Those are difficult questions without good answers right now. LatencyTOP is a Linux tool for software developers (both kernel and userspace), aimed at identifying where system latency occurs, and what kind of operation/action is causing the latency to happen. By identifying this, developers can then change the code to avoid the worst latency hiccups.”
It is interesting that Intel has done so much work on creating profiling and performance tools for the end user. First powertop and now latencytop, tackling problems and things that otherwise would be a slower, much more tedious process to analyze.
While not as glitzy (or as large) as many projects these tools are a great asset to linux. It will be interesting to see if Intel continues to come up with *top style tools for different problem areas in performance that otherwise might be ignored.
Agreed. People often don’t realize that the first step to fixing any performance problem is being able to measure the problem accurately, so you don’t waste time fixing the wrong thing. Often the bottleneck is where a developer would never expect it to be.
Encouraging customers to look at latencies for performance analysis is really important.
I quickly browsed the code, and it appears that this is implemented by statically defining latency metrics in the kernel. Wow! Was this written a decade ago?
Performance analysis these days is about dynamic tracing using DTrace, which appears in Solaris 10, MacOS X, and other operating systems. DTrace is able to read these latencies and *thousands* more, in *all* layers of the software stack *without* modifying them.
The latencytop engineers need to look at DTrace and not reinvent a wheel that is already obsolete. DTrace does use statically defined trace points at times, but when appropriate and complementary to the dynamic tracing system.
If this tool does get customers to think more carefully about latency metrics, then that will certainly be valuable. All roads lead to DTrace.
Linux 2.6.24 has a static probing subsystem, why the latencytop patches don’t use it is beyond me
Dtrace’s license is not compatible with the license of the linux kernel. So we have to wait until either Linus decides to go for GPL v3 or Sun allows DTrace to be used in the linux kernel…
You might want to read through the comments here:
http://blogs.sun.com/ahl/entry/dtrace_knockoffs
which was also discussed on osnews here:
http://osnews.com/comments/18388
Based on everything I know about the issue, the actual stopper for DTrace on Linux is Not Invented Here Syndrome. License discussion led to debate about what is or isn’t considered a derived work of the kernel, and ways Linux can work around that to include DTrace.
What about SystemTap? Isn’t it sponsored by Intel? I wonder if all these different utilites couldn’t just be integrated with SystemTap, instead of being their own thing. I’ll still have to give it a try, PowerTop is a very cool utility that has no doubt saved me plenty of battery life.