Re: Experiences with kprobes

[Baruch Even <baruch at ev-en dot org>]

Roland McGrath wrote:
> For finding hot spots with low overhead, oprofile may be the better tool
> for what you need.

I'm also using oprofile, but since it only gives statistical information 
and not specific per ack its data is used to direct more accurate checks 
in the correct direction.

>  That said, we are certainly aware of kprobes
> performance being an issue and I suspect it will get somewhat better as the
> project develops.  Something we have been looking for is specific
> quantitative definitions of what "fast enough" is for various applications.
> If you have some estimate of the overhead you are seeing, the frequency of
> hits in your load scenario, and the (lower) range of overhead that would
> make probing techniques useful to you that are prohibitive at the moment,
> this would be good information to feed into our performance goals.

I have now rechecked my work with kprobes trying to see what would help 
me but couldn't find a way to give numbers. I did notice an error in my 
exit probe location and that seemed to make a big difference (I was 
measuring something different than what I wanted), so the current system 
is useful already though the overhead of about 7000 clocks that I have 
now over the old method _seems_ too much for me.

It's a bit hard to defend that my measurements are valid when the 
overhead is twice than what I'm measuring.

I guess it doesn't align with the systemtap group objectives but I'd be 
happy to see a static instrumentation tool for the kernel to allow me to 
insert the code I need after compilation. Hopefully such a method would 
have a lower overhead.

Baruch