posted

0 Comments

KernelShark, the open source graphical user interface or tracing data that gives users a view of the events happening within the Linux kernel, has proven useful for many kernel developers—but it’s not without its limitations. That’s why we’re now in the process of completely rewriting KernelShark, rebuilding it on a more solid platform and readying it to expand in a number of exciting ways.

KernelShark

First, it has been rewritten to be based on Qt, an open source GUI library that we believe will facilitate expanding KernelShark with new features. The original version used GTK, but we’ve found Qt to be a more stable interface as GTK’s API regularly becomes obsolete. That being said, the choice to move to Qt was rather easy to make. Once the Qt version is equivalent to the previous GTK version, it will be released as 1.0. Not only has KernelShark been updated from GTK to Qt, but because it has been rewritten, we had the luxury of designing it better than it was before. Where the old KernelShark could take minutes to load a gigabyte file, the new 1.0 release will be able to view that same file within seconds.

After 1.0 is released, we will start extending it immediately. Our first goal will be making KernelShark user modifiable. You’ll be able to write plugins (in C, C++ or Python) that let you manipulate the displaying of graphs and change the visualization, customized to suit your needs. The interface of KernelShark 1.0 is also slightly different than the one before. There are no more pop-ups over the mouse; instead, the data is displayed in a constant location at the top. But the interaction is much faster than it was before. Zooming in and out is much smoother and can be done with the use of the mouse wheel.

Future versions of KernelShark will have various graphical screens. Some will display flame graphs while others will take advantage of the new histogram functionality within the Linux kernel. It will allow you to write a script that selects two events, such as a schedule wakeup and a schedule switch (which is when the specific event runs on the CPU), record when each takes place and then create a histogram view showing patterns of latency for that particular event type. We’re hoping to create something similar with flamegraphs, which show what functions are taking up the most processing time in a CPU.

In addition, KernelShark will be able to save sessions within a JSON format file. That way KernelShark can come back to the exact place it left off when you exited. A new capturing (recording) feature has been added where it is easier to start a trace, with no need to run KernelShark as root. When a capture is executed, a pop-up will appear that will ask you for the root password in order to get the permissions to perform the trace operations.

Currently, KernelShark only allows you to trace the kernel that you are working on. Soon, it will be extended to be able to trace guests along with the host events. This will give you a single view of the events that are happening, interweaved between hosts and guests. And we aren’t stopping there—we’re also looking into ways to incorporate trace data throughout the cloud. Just imagine what could be done if you could see the events that happen from the time you initiate a service and then be able to see how it was executed, all the way through to the point that you received a response.

Eventually, we’re hoping KernelShark will have use beyond the Linux kernel. One of the changes in the design of KernelShark is that it is not as dependent on the trace.dat file. KernelShark is broken into two parts: one is the visualization and the other is reading of the data file. This change will allow KernelShark to read not only trace.dat formats, but also perf and Common Trace Format files. We’re hopeful that developers will be able to import trace data from other operating systems and then deploy KernelShark’s graphics power to help resolve their bottlenecks.

We expect to have the new version ready sometime in the fall. If you want to help out or contribute, let us know by emailing linux-trace-devel@vger.kernel.org. Otherwise, be on the lookout for an announcement post when KernelShark 1.0 is live.

Stay tuned to the Open Source Blog for updates on KernelShark and be sure to follow us on Twitter (@vmwopensource).