This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH 1/3] systemtap: kernel marker tapset
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: systemtap-ml <systemtap at sources dot redhat dot com>, "ltt-dev at lists dot casi dot polymtl dot ca" <ltt-dev at lists dot casi dot polymtl dot ca>, Hideo AOKI <haoki at redhat dot com>, Takahiro Yasui <tyasui at redhat dot com>
- Date: Fri, 12 Sep 2008 16:02:00 -0700
- Subject: Re: [PATCH 1/3] systemtap: kernel marker tapset
- References: <48CAEB24.8060807@redhat.com>
Masami Hiramatsu wrote:
> Here is a patch which adds a tapset for kernel markers.
> this tapset supports lttng's kernel marker(+my cpuid patch) too.
This looks very nice! It will be great to finally use markers for lower
overhead probing...
In the "Context" documentation, you tend to restate the event, but I'm
looking for a description of which process environment is active when
the event occurs. For some events, it's not obvious which process I
would see if I checked pid(), execname(), etc. For example, does
marker.process.fork fire in the parent or the child? Does
marker.scheduler.switch fire from the previous or next task?
Eventually, we'll also want to push these to a higher namespace without
the marker prefix. Users generally shouldn't care *how* an event is
captured; stap should just pick the best option available. Something
like:
probe process.exit =
marker.process.exit!, // markers
process("*").end!, // utrace
kernel.function("do_exit") // kprobe
Josh