Re: Co-oridnate system for adding probes

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

Hi -


brad.chen wrote:

> [...]  Clearly performance analysts have very different needs from
> people debugging the kernel, and I'm wondering about how this is
> going to reflect itself in the design of the system.

I see nothing substantially related to this issue in the list.

> [...]
> > 1) When a particular event like timer or page fault  etc. occurs.
> I think we want to be explicit that we are talking about hardware
> events, right? My assumption is that software events would be
> captured through the first set of probe types. [...]

I don't think "kprobes" == "software events".  kprobes may not be the
only mechanism available to set probe points on addressed pieces of
executable code.  Anyway, we're just trying to get a sense of the
scale / dimensionality of the probe point space.  It's not important
that we already identify the "basis vectors" (some minimal mechanism
set to provide complete coverage).

For what it's worth, here is a possible syntax for a whole range of
probe points we've discussed (and some we haven't).  Many of them will
map to a list of instances of the other types.

  lkst("process_contextswitch")
  syscall("execve").return
  syscall("*")
  kernel.function("wait_for_godot")
  kernel.function("name").line(10)
  kernel.source("mempool.c").line(5004)
  kernel.source("mempool.c").function("*")
  kernel.address(0xdeadbeef)
  kernel.module("driver.ko").function("name").return
  kernel.module("cpqarray.ko").jumptable("ida_fops")
  kernel.watch("datasymbol").write
  user("fche").inode("/bin/vi").function("refresh")
  user.inode("/lib/libc.so.6").function("malloc").return
  time.real.hz(500)
  time.virtual.jiffies(100)
  perfcounter("tlbmiss").count(4000)
  resource.freemembelow(50) # pages?

- FChE