This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC PATCH tip 0/5] tracing filters with BPF
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Alexei Starovoitov <ast at plumgrid dot com>
- Cc: systemtap at sourceware dot org
- Date: Thu, 5 Dec 2013 15:18:20 -0500
- Subject: Re: [RFC PATCH tip 0/5] tracing filters with BPF
- Authentication-results: sourceware.org; auth=none
- References: <1386044930-15149-1-git-send-email-ast at plumgrid dot com> <87fvq9cwlk dot fsf at tassilo dot jf dot intel dot com> <CAMEtUuzweYxqwoaYH+J5a2uRM+PFcBH+Pb8Z_ALPUMp+QFz1tQ at mail dot gmail dot com> <CAMEtUuzWLcTOeQSrhEQHVn7DbuoJn7bNek9-toQ9xZYzya3-ag at mail dot gmail dot com> <y0meh5rs2eq dot fsf at fche dot csb> <CAMEtUuzQXo2kwoBUxq0PKOWA=T4WXtg3Bj8vzYvQquzW+isMSA at mail dot gmail dot com> <20131205194426 dot GA22245 at redhat dot com> <CAMEtUuwV1QRWkfA1y_r-B0n4T3daATti7_+jE2MLC6LgDNWMLg at mail dot gmail dot com>
Hi -
(Hopping over from https://lkml.org/lkml/2013/12/5/516)
> this is over 1M iterations in a hot cache, so we're talking nsec
> differences for single event.
Yup.
> Looking at generated enter_real_tracepoint_probe_0(), stap is doing
> a bunch of stp_context checks, inits a dozen internal variables and
> only then jumps into probe, so not totally unexpected to see higher
> entry overhead. [...]
Yeah, there is a lot of boilerplate code (much of it is
#ifdef-compiled out, depending on stap options). Some of it is
safety-oriented that you might end up needing too
(preemption-disabling, stack-depth checking). Some of it is probably
overdone, line some flavours of overload detection, for the case where
can can statically analyze and find no loops/recursion.
- FChE