This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

kernel summit session on systemtap


Hi -

Yesterday morning, we had a 90-minute session on topics touching
systemtap.  Though there were several serious concerns raised, it went
better than I had expected.

Here are some things we need to work more on:

- Making it dead easy for kernel guys to build and use the thing.
  It's hard to say how what problems they run into since only the rare
  bug report gets sent, but some possibilities could be:
  - be able to work against an un-installed kernel build tree
  - add buildid checking
  - bundle elfutils sources for the distro-challenged :-)
  - other ideas, please!

- It's time to really improve & shrink debuginfo.  Enough said.

- We need to test constantly agaist linus/linux-next type git trees,
  at least to confirm that the runtime works.  There is a perception
  that it breaks often, and this in turn is driving the impulse to
  pull the runtime into the kernel.  If we can more aggressively
  handle the problem, the impulse would die off.  We could still of
  course push some of the runtime upstream, but that could happen for
  stronger technical reasons rather than kneejerks.  Linus hinted at
  going through akpm since he's such a pushover :-)

- Stability.  Kernel crashes are an instant and long-lasting turn-off,
  even to the point of mean laughter.  We need to urgently and deeply
  stress-test and robustify our kernel-side foundations (kprobes,
  utrace, uprobes, runtime).


Here are some areas I am no longer that worried about:

- The general approach of synthesized modules vs.  bytecode
  interpeters.  This dtrace-favouring marketing canard was brought up
  yet again ("systemtap is unstable because ...", but before I got a
  chance to rebut, Linus himself said that VMs are not a good answer
  either.  With the above "foundation robustness" problem improved,
  there will be evidence that should satisfy more skeptics.

- Markers.  There was a concensus that the kernel needs more of them.
  Well, there was quite some indecision over who should champion them,
  but a tasteful set of some dozens should be uncontroversial.  A good
  start to prime the pump would be some baby kernel-side tool that
  connects markers to an existing tracing channel, perhaps one little
  piece of lttng.

- The tool's generality.  Linus is rightly skeptical of a tool that
  aims too high and turns out to be too hard to use.  (I believe
  "piece of shit" was his shock-value opening comment.  :-) He`s also
  annoyed at the continuing proliferation of tracing widgets.  There
  was a short spurt of support for increasing the reach of tools like
  "latencytop" (speculating that it "solves the problems for 80% of
  people"), but then many people spoke of important problems that only
  a broader tool can address.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]