Slashdot Mirror
Kernel Tracing With LTTng On Ubuntu Maverick
francis-giraldeau writes "Linux Tracing Toolkit (LTTng) provides high-performance kernel tracing for Linux. This is the killer app for system level debugging and performance tuning. It's now easier than ever to install, with packages released for Ubuntu Maverick. The short introduction to kernel tracing shows how to interpret a simple kernel trace and relate it to strace. I would like to ask Slashdot readers what they would expect as features for a kernel tracing analysis tool, because I'm starting my PhD on this topic and looking for ideas. Also, I wonder why LTTng is not mainline yet. Will Linus Torvalds see the light in 2011?"
What is the goal of your work? Do you want to compare kernel tracing solutions and identify critical features in the process of coming up with a reasonable taxonomy? Do you want to implement something? Do you have a specific application for kernel tracing (e.g. informing performance tuning measures in enterprise environments which would probably be of interest to businesses)? Just throwing together a list of desired features is not going to be of interest to anyone, I guess. You have to come up with a motivation for each of the features, argue why this feature is necessary for the application at hand or for any application of kernel tracing in general, cite literature that gives evidence for your assumptions and conclusions. Maybe if you told the people what kind of work you're interested in and what the interest of your advisor(s) is, in which reasearch context (department, university) you are working, they could make sensible suggestions as to which features might be interesting to you.
A problem already solved with DTrace on Solaris http://docs.sun.com/app/docs/doc/817-6223
Why does the OP mention the Ubuntu package when the project releases a tarball?
There is no need to make news distro-centric when it does not need to be. The submitter should check to see what other binary packages are available or not mention them at all.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
http://docs.sun.com/app/docs/doc/817-6223
Maybe I'm reading slashdot too early on a weekend morning, but I find the last statement of the summary particularly offensive. It seems like everyone who has some sort of kernel widget wants a PR campaign to get it included in the mainline. How about you finish your Ph. D. first and provide some convincing evidence as to why every single person running Linux has to have the tool? The trace tools are available as a package for anyone who wants them now. Why should the mainline be burdened with maintaining the package unless a significant number of users need it?
Atlas stands on the earth and carries the celestial sphere on his shoulders.
Also, I wonder why LTTng is not mainline yet
Well, a bit of searching would have answered your question
The LTTng maintainer has been working for months (years?) to get the kernel tracing into a decent shape. These days the Linux tracing support is wonderful, and not just for LTT - perf, ftrace and systemtap are awesome tools (and more powerful than LTTng in some ways). In fact perf can do all what the web page says and it seems to be more simple for my taste
With DTrace, you have to know what you are looking for in advance, while LTTng can trace in background in flight recording mode and record everything that is going on. Then, afterward you can have all the information you need, and this is invaluable when you have a hard to reproduce bug!
are you talking about a trace or a data analysis tool? if you plan to use LTT to get a trace and then help the user analyse it, maybe you are more into analysis than tracing. then your question could be a bit misleading. Anyway, you would probably end up trying it all out, adding some features to make it all easier to trace as you try to use the existing stuff and analyse the results and so on as you progress. And if you are into trace data analysis (as opposed to tracing) then your domain of kernel trace data analysis is just one application of data analysis. there you need to look into data analysis methods, statistical methods, machine learning, etc. depending on what kind of analysis you like and need. it is somewhat different depending on your goals such as performance data, behaviour trace and analysis, etc.. for some more behaviour related stuff you can look into domains of program comprehension, behaviour analysis and modeling in general, software reverse engineering, specification mining, etc. anyway, at least i would be interested to see some results on this kind of stuff if you go with it and have some means to follow on it and provide feedback..mainstream or not most of this stuff never ends up anywhere or is available at all.
Right. Because everyone knows the best place to develop, debug, and profile code is on a production machine, and the person doing the development should be a system administrator, preferably with minimal experience.
I would say many people do know that the best place to understand the performance of a system in production is in production. If the vendors support techs can give an admin commands to run and know that a typo here or there will not result in a panic then that is a very useful feature.
He has expressed similar sentiments more recently as well (eg from 2007 on git's use of c vs c++)
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
Do you even lift?
These aren't the 'roids you're looking for.