RE: cost of kprobe and jprobe operations

["Chen, Brad" <brad dot chen at intel dot com>]

I would agree that trying to commit to a cycle budget
at this time would be premature. I don't think it's
too early to talk about some scenarios we intend to
support. My rationale for suggesting performance goals 
is to avoid optimization for optimization's sake. 
Without performance goals, it's difficult to work 
together on what is "good enough" performance.

What do you think? If we can't talk about performance
in exact terms than is there a relative or abstract way
to approach the question?

There are a few external reference points that might 
guide what we see as acceptable performance:
- DCPI and OProfile are relevant previous work
- It would be nice to be competitive with DTrace
- In my experience, customers generally think < 5%
  is acceptable overhead on production systems. 
Would anybody disagree with these as relevant points 
of reference for systemtap performance? Of course, 
overhead depends entirely on how systemtap is used. 

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Tuesday, February 22, 2005 1:54 PM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: cost of kprobe and jprobe operations

Hi -


> [...]
> These performance discussions might be more meaningful if 
> we had explicit performance goals for systemtap. [...]
> Any thoughts on defining performance goals for systemtap?

I don't think picking numbers does harm, but I don't know how
much good that does either.  Would we stop-ship a systemtap
implementation that didn't meet the goals?  In the abstract,
should one opt to optimize vs. extend functionality?  Maybe
these questions should be put aside until something runnable
exists as a point of reference, when actual decisions might
need to be made.


- FChE