Re: kernel summit session on systemtap

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

Hi -

On Wed, Sep 17, 2008 at 06:13:49PM -0400, Theodore Tso wrote:
> [...]
> > - It's time to really improve & shrink debuginfo.  Enough said.
> 
> The more I've played with debuginfo, the more I've been convinced that
> at least for me, the costs vastly outweight the benefits.  [...]

Right.  We (systemtap and associated tools folks) are working on
- improving quality (benefits) of dwarf
- shrinking dwarf dramatically
- if all else fails, dwarf subsetting

Changing kernel build flags is of course possible, but it is not our
place to mandate that.


> [...] Quite frankly, these days the main reason why I haven't been
> 	playing with Systemtap much lately is because I'm tired of
> 	waiting for compiles to complete when compiling with
> 	debuginfo.  [...]

(By the way, do you build distro-style kernels on your laptop, with
allmodconfig or somesuch, or something more linus-sized?)


> One HUGE advantage has over DTrace is that it has certain constructs,
> such as its default report generation, and speculative tracing, which
> means you can do things on a single command line, i.e.:
> 
> dtrace -n 'syscall::exec*:return { trace(execname); }'
> 
> By default dtrace will print a line for each probe that fires, and if
> you use the trace command, it will print the contents of the name.

stap -e 'probe syscall.exec* { log(name." ".execname()) }


> Or take this example:
> 
> % dtrace -n 'syscall:::entry { @num[pid, execname] = count(); }'
> 
> This will automatically print out the number of system calls each
> process (printed with pid and execname) [...]

stap -e 'probe process.syscall { num[pid(),execname()] <<< 1 } global num'


> You can do the same thing in systemtap, but you have to do it as a
> full script, and you have to explicily have a print command [...]

Your information is slightly obsolete.  We just added some such
automation, and can do more.


> (Such as simulating thread local variables using tid's --- sorry,
> but that's just LAME.  :-)

We can bring our old 'thread->FOO' / 'process->FOO' syntax back,
No big deal.


- FChE