Re: [Announce] pybootchartgui

[Soeren Sandmann <sandmann daimi au dk>]

Chris Wilson <chris chris-wilson co uk> writes:

> On Sun, 2009-02-22 at 11:46 +0100, Anders Norgaard wrote:
> > Behdad asked here and on his blog[1] for a python version of bootchart
> > that would be hackable and extendable for more startup profiling
> > tasks.
> > 
> > Now Henning Niss and I have such a port in a working state. The code
> > has been reduced from ~3k to ~1k SLOC in the port to python.
> > 
> > http://code.google.com/p/pybootchartgui/
> > 
> > It reads the same files as the original bootchart and it has been
> > tested on Ubuntu and Fedora.
> > 
> > We happily accept feature requests and patches.
> 
> That does look good, and it looks like it should be complementary to
> using sysprof for inspecting whole-system activity. So how difficult
> will it be to extend sysprof to both capture and display the same
> information? I'm hoping that with the tracing frameworks being developed
> within the kernel, we can now access all the profiling information
> without additional modules, and so it should just be a matter of
> integration. (I'm aiming for understatement of the year ;-)

Well, I do have an interest in having disk profiling in sysprof. The
UI I had in mind was something where you would get a timeline instead
of the "Samples: x" label. This timeline would then show both CPU and
disk activity, much like bootchart does. You would be able to select
an interval on it, and the corresponding data would be displayed. Disk
and CPU should maybe be selectable separately.

The data that would be required from the kernel is a stacktrace every
time disk I/O is started, ideally coupled with information about *why*
the I/O was started (page fault, readahead, plain old read etc.)

In general though, I'd be careful about "integrating" all data sources
into one big application. Part of the appeal of both bootchart and
sysprof is that they are conceptually simple and focused tools. It
isn't clear to me that combining them into one application is
necessarily a win.

Soren