This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: next steps
- From: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- To: Richard J Moore <richardj_moore at uk dot ibm dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, sugita at sdl dot hitachi dot co dot jp
- Date: Thu, 29 Sep 2005 21:59:02 +0900
- Subject: Re: next steps
- References: <OFE86A61E4.88F07BB2-ON41257083.00807F4B-41257083.008134CF@uk.ibm.com>
Hi, Richard
Richard J Moore wrote:
> However, for performance measurements, once need a mechanism that perturbs
> the system timing as little as possible - even if some events are lost.
I agree.
> I believe djprobes attempts to fulfil this need, but if my understanding is
> correct there are some unfortunate restrictions to its deployment.
As you understood, djprobe have some restriction. But I think
the restriction is not so huge. Djprobe can be used to probe
most of kallsyms address. I believe that is good enough to use
in the real work. And also we can use kprobes instead of djprobe,
when we need to put probes that can not be covered by djprobe.
So, djprobe can coexist with kprobes and it can be deployed, I think.
> So, I'm
> lodging a request that this issue be further discussed at the very least to
> determine whether there is a real need to address it, which I believe
> there. For example using the current mechanism to trace interrupts from a
> Gb ethernet NIC is not going to work particularly well.
All discussions are welcome.
Best Regards,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp