From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Luigi Rizzo <lrizzo@google.com>
Cc: linux-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Greg KH <gregkh@linuxfoundation.org>,
naveen.n.rao@linux.ibm.com, ardb@kernel.org,
Luigi Rizzo <rizzo@iet.unipi.it>, Paolo Abeni <pabeni@redhat.com>,
giuseppe.lettieri@unipi.it,
Jesper Dangaard Brouer <hawk@kernel.org>,
mingo@redhat.com, acme@kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
peterz@infradead.org
Subject: Re: [PATCH v3 0/2] kstats: kernel metric collector
Date: Thu, 27 Feb 2020 00:11:38 +0100 [thread overview]
Message-ID: <878skpx7th.fsf@toke.dk> (raw)
In-Reply-To: <CAMOZA0Lzf2r7rFvgBEWpf-B=wXvyED2CxfzuO7qUA_qVsNtL7g@mail.gmail.com>
Luigi Rizzo <lrizzo@google.com> writes:
> - the runtime cost and complexity of hooking bpf code is still a bit
> unclear to me. kretprobe or tracepoints are expensive, I suppose that
> some lean hook replace register_kretprobe() may exist and the
> difference from inline annotations would be marginal (we'd still need
> to put in the hooks around the code we want to time, though, so it
> wouldn't be a pure bpf solution). Any pointers to this are welcome;
> Alexei mentioned fentry/fexit and bpf trampolines, but I haven't found
> an example that lets me do something equivalent to kretprobe (take a
> timestamp before and one after a function without explicit
> instrumentation)
As Alexei said, with fentry/fexit the overhead should be on par with
your example. This functionality is pretty new, though, so I can
understand why it's not obvious how to do things with it yet :)
I think the best place to look is currently in selftests/bpf in the
kernel sources. Grep for 'fexit' and 'fentry' in the progs/ subdir.
test_overhead.c and kfree_skb.c seem to have some examples you may be
able to work from.
> - I still see some huge differences in usability, and this is in my
> opinion one very big difference between the two approaches. The
> systems where data collection may be of interest are not necessarily
> accessible to developers with the skills to write custom bpf code, or
> load bpf modules (security policies may prevent that). One thing is to
> tell a sysadmin to run "echo trace foo >
> /sys/kernel/debug/kstats/_config" or "watch grep CPUS
> /sys/kernel/debug/kstats/bar", another one is to tell them to load a
> bpf program (or write their own one).
With BPF the solution for this is to distribute a tool that does all the
setup for the user. Basically the userspace equivalent of what you're
proposing to include into the kernel here. You can make this arbitrarily
user-friendly, up to and including having a GUI list all the functions
available in the running kernel and letting the user just click on the
one to measure :)
-Toke
next prev parent reply other threads:[~2020-02-26 23:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 13:50 [PATCH v3 0/2] kstats: kernel metric collector Luigi Rizzo
2020-02-26 13:50 ` [PATCH v3 1/2] " Luigi Rizzo
2020-02-26 14:48 ` Paolo Abeni
2020-03-10 13:58 ` kbuild test robot
2020-03-10 13:58 ` kbuild test robot
2020-03-10 16:44 ` kbuild test robot
2020-03-10 16:44 ` kbuild test robot
2020-03-11 0:08 ` kbuild test robot
2020-03-11 0:08 ` kbuild test robot
2020-03-11 3:30 ` kbuild test robot
2020-03-11 3:30 ` kbuild test robot
2020-02-26 13:50 ` [PATCH v3 2/2] kstats: kretprobe and tracepoint support Luigi Rizzo
2020-02-26 15:00 ` [PATCH v3 0/2] kstats: kernel metric collector Toke Høiland-Jørgensen
2020-02-26 16:31 ` Alexei Starovoitov
2020-02-26 17:26 ` Luigi Rizzo
2020-02-26 19:14 ` Peter Zijlstra
2020-02-26 20:49 ` Alexei Starovoitov
2020-02-26 23:11 ` Toke Høiland-Jørgensen [this message]
2020-02-27 10:31 ` Luigi Rizzo
2020-02-27 12:13 ` Toke Høiland-Jørgensen
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=878skpx7th.fsf@toke.dk \
--to=toke@redhat.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=giuseppe.lettieri@unipi.it \
--cc=gregkh@linuxfoundation.org \
--cc=hawk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrizzo@google.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=naveen.n.rao@linux.ibm.com \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=rizzo@iet.unipi.it \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.