public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: William Cohen <wcohen@redhat.com>
To: systemtap@sourceware.org
Subject: Re: Getting systemtap examples working with --bpf backend
Date: Mon, 20 May 2019 19:52:00 -0000	[thread overview]
Message-ID: <86911ca2-5c65-9c79-0d4c-5dabb9331a60@redhat.com> (raw)
In-Reply-To: <6d85269b-e182-5208-270b-a2f3c4369d24@redhat.com>

On 5/16/19 9:41 AM, William Cohen wrote:
> I noticed https://elinux.org/images/d/dc/Kernel-Analysis-Using-eBPF-Daniel-Thompson-Linaro.pdf mentioned on page 29 that many of the systemtap examples did not work with the bpf back end and led to frustration.  Today I took a quick survey of how badly the examples are broken by adding the following line to the beginning of the run_command function in check.exp trying:
> 
>     set command [ string map {"stap " "stap --bpf "} $command ]
> 
> Most of the examples fail.  There are a few that actually do appear to run are just doing things in probe begin or end handlers (with the exception of cachestat*) :
> 
> PASS: systemtap.examples/general/ansi_colors run
> PASS: systemtap.examples/general/ansi_colors2 run
> PASS: systemtap.examples/general/helloworld run
> PASS: systemtap.examples/memory/cachestat run
> PASS: systemtap.examples/memory/cachestat_bpf run
> PASS: systemtap.examples/memory/kmalloc-top run
> 
> The non-bpf cachestat works because it just probes raw functions. Most examples fail because of various missing syscall.*/syscall_any probe points and gettimeofday_*() functions.  The time functions should be something easy to get working in bpf as there is already a nanosecond time function and its results could be scaled for microseconds, milliseconds, and seconds.
> 
> -Will
> 

Hi,

The cachestat_bpf test has been folded into the cachestat test to minimize duplication.  The helloworld tests has been set to run with the bpf back end.  The kmalloc-top test is actually a perl script isn't running the generating code with the bpf backend.  The ansi_colors and ansi_colors2 compile and run but their output is not checked and it results do not have the proper color formatting like the regular systemtap version (due to not handling octal escapes, PR23559)

The systemtap example heavily leverage the systemtap tapsets.  Currently, the bpf has few tapsets.  Things like syscall.* probe points and gettimeofday_* functions are not available for systemtap bpf generation.  However, probably don't want to blindly duplicate all the tapsets in the tapsets/linux directory for tapsets/bpf.

There is already a bpf ktime_get_ns available.  If there was a time offset generated, then it should be possible to have gettimeofday_* functions for bpf, allowing some additional scripts to work. Alternatively, don't worry about the offset at the moment as most of the example are taking the difference between two gettimeofday_* function calls.

A number of examples are using multdimensional-arrays  this can also be implicit when using the @entry() operation. However, these examples are not going to work because of PR23478.  Examples such as hugepage_cow_delays fail in the folowing manner:


attempting command stap --bpf -p4 hugepage_cow_delays.stp
OUT semantic error: unhandled multi-dimensional array: identifier 'gettimeofday_us' at hugepage_cow_delays.stp:8:37
        source:     <<< (gettimeofday_us() - @entry(gettimeofday_us()))
                                                    ^

Pass 4: compilation failed.  [man error::pass4]
child process exited abnormally
RC 1


-Will

  reply	other threads:[~2019-05-20 19:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 13:41 William Cohen
2019-05-20 19:52 ` William Cohen [this message]
2019-05-21 17:11   ` William Cohen
2019-05-22 20:51     ` Frank Ch. Eigler
2019-05-22 21:12       ` William Cohen
2019-05-22 21:39         ` Serhei Makarov
2019-06-03 15:51 ` William Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86911ca2-5c65-9c79-0d4c-5dabb9331a60@redhat.com \
    --to=wcohen@redhat.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).