ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Julien Desfossez <jdesfossez@efficios.com>,
	daolivei <daolivei@redhat.com>, bristot <bristot@redhat.com>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Pulling away from the tracing ABI quicksands
Date: Tue, 4 Jul 2017 16:51:10 +0200	[thread overview]
Message-ID: <20170704145110.GD7287@worktop> (raw)
In-Reply-To: <20170629221245.489760b1@gandalf.local.home>


Yay, tracing fight!! :/

On Thu, Jun 29, 2017 at 10:12:45PM -0400, Steven Rostedt wrote:
> On Thu, 29 Jun 2017 18:51:14 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > But yes, I was talking about something very similar to what I think
> > Peter is talking about - the ability to attach a ebpf script to
> > kprobes and extract data dynamically. We've supported ebpf tracepoints
> > for years afaik, what is actually missing from using that for whatever
> > particular extension people want to use?
> 
> Well, I don't want to put words in his mouth, but as he's probably
> currently putting mush in a baby's mouth, so I'll do it anyway. ;-) We
> were talking about making the static tracepoints more "dynamic". I'm not
> sure he's ever used eBPF with tracing.

So my concerns/objections are two-fold:

 - I want only a single static tracepoint in the code.

 - I want only a single 'event' associated with this in userspace.

   (in particular I only see confusion happening when we have:
    sched_switch_fair, sched_switch_rt, sched_switch_deadline events for
    the exact same event; people will forget to enable one or more and
    wonder WTF they have holes in their traces)

These are not strange constraints / demands in my book. Just turns out
its 'difficult' to pull off or something.  I'm in fact fine with simply
adding bits to the one tracepoint we have; although others (that'd be
you Steve) are not because expensive.

Further complications seem to stem from the fact that I use the tracefs
interface exclusively. I don't know how to use perf or trace-cmd or any
of that new fangled stuff to do tracing -- nor do I really care, it
works for me (same why I'm happy with sysvinit, I don't _want_ to have
to relearn my 20+ year old sysadmin skillz, there's better things in live
to spend time on, that baby you mentioned for example).

So on that same vein, I'd be entirely helpless using eBPF to do tracing,
that's even more complicated. That said, I don't typically need this
crud anyway, I just change my kernel and rebuild, reboot and am happy,
that's far easier than trying to figure out how eBPF works.


In any case, baby vomit is more fun that this subject :-)

  parent reply	other threads:[~2017-07-04 14:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 21:20 Mathieu Desnoyers
2017-06-29 23:55 ` Steven Rostedt
2017-06-30  0:03   ` Linus Torvalds
2017-06-30  0:32     ` Steven Rostedt
2017-06-30  0:41       ` Linus Torvalds
2017-06-30  0:59         ` Steven Rostedt
2017-06-30  0:52       ` Steven Rostedt
2017-06-30  1:00         ` Linus Torvalds
2017-06-30  1:16           ` Steven Rostedt
2017-06-30  1:27             ` Steven Rostedt
2017-06-30  1:51               ` Linus Torvalds
2017-06-30  2:12                 ` Steven Rostedt
2017-06-30  2:34                   ` Linus Torvalds
2017-06-30  2:48                     ` Steven Rostedt
2017-06-30  2:58                     ` Alexei Starovoitov
2017-06-30  3:02                       ` Steven Rostedt
2017-06-30  3:20                         ` Steven Rostedt
2017-07-27 14:35                           ` Mathieu Desnoyers
2017-07-27 15:57                             ` Steven Rostedt
2017-06-30 18:24                         ` Josef Bacik
2017-06-30 18:29                           ` Steven Rostedt
2017-06-30 18:30                             ` Steven Rostedt
2017-06-30 18:37                               ` Josef Bacik
2017-07-06 19:10                                 ` Steven Rostedt
2017-07-21 21:45                                   ` Mathieu Desnoyers
2017-07-21 23:15                                     ` James Bottomley
2017-07-22  2:18                                     ` Steven Rostedt
2017-07-23 16:24                                       ` Josef Bacik
2017-07-23 21:25                                         ` Steven Rostedt
2017-07-04 14:51                   ` Peter Zijlstra [this message]
2017-06-30  1:38             ` Linus Torvalds
2017-06-30  1:45               ` Steven Rostedt

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=20170704145110.GD7287@worktop \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=daolivei@redhat.com \
    --cc=jdesfossez@efficios.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=mingo@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox