Re: kernel summit session on systemtap

["Frank Ch. Eigler" <fche@redhat.com>]

Hi, Ted -

On Thu, Sep 18, 2008 at 11:18:43AM -0400, Theodore Tso wrote:
> [...]
> > - improving quality (benefits) of dwarf
> > - shrinking dwarf dramatically
> > - if all else fails, dwarf subsetting
> 
> What do you think is the timeline for this happening?  I assume this
> requires changes to gcc, right?  So would an estimate of 6-9 months,
> minimum, be a fair one [...]

For improving debuginfo quality, yeah.  For subsetting or compressing,
we can probably attack the problem with separate postprocessing tools
that could be ready sooner.



> "make install" to strip out the debuginfo so that the partition
> containing /lib wouldn't run out of space.  Right now I manually
> install the full set of module files in /usr/lib/debug/lib/modules/... via:
> 
> 	make INSTALL_MOD_STRIP=1 install_modules
> 	make INSTALL_MOD_PATH=/usr/lib/debug install_modules

That's a clever alternative to using the separate-debuginfo style
stripping.


> > (By the way, do you build distro-style kernels on your laptop, with
> > allmodconfig or somesuch, or something more linus-sized?)
> 
> I do both.  The distro-style kernels are the ones that I build with
> debuginfo information, and it's been useful for playing around with
> systemtap, but the moment I need do any serious development work, I
> tend to fall back to a limited subset of compile options, generally
> without any modules, and printk debugging.  

OK; is there some obstruction in the way of using systemtap on your
'serious development' kernels?


> Once we get a useful circular buffer, I'd probably start logging to
> the circular buffer and use grep as the alternative to systemtap or
> printk debugging.

OK. 


> As a result, I've had no motivation to create any tapsets, since at
> least for my own personal needs, the costs of creating the debuginfo
> so that SystemTap would be useful for my personal needs just far
> outweighs the benefits.

My recollection of the ksummit yak was that the sort of tapset that
kernel people would be willing to help write/maintain consisted of
compiled-in instrumentation like markers, or whatever event layer
comes on top of the new ringbuffer widget.  If that's done right, it
should not require debuginfo for systemtap to hook in.


> > Your information is slightly obsolete.  We just added some such
> > automation, and can do more.
> 
> Glad to hear it.  I suspect then that this page:
>      http://sources.redhat.com/systemtap/wiki/SystemtapDtraceComparison
> is also slightly out of date.

Yeah.


- FChE