BPF Archive on lore.kernel.org
 help / color / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	dtrace-devel@oss.oracle.com, linux-kernel@vger.kernel.org,
	mhiramat@kernel.org, acme@kernel.org, ast@kernel.org,
	daniel@iogearbox.net, peterz@infradead.org
Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use
Date: Thu, 23 May 2019 19:08:51 -0700
Message-ID: <20190524020849.vxg3hqjtnhnicyzp@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20190523215737.6601ab7c@oasis.local.home>

On Thu, May 23, 2019 at 09:57:37PM -0400, Steven Rostedt wrote:
> On Thu, 23 May 2019 17:31:50 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> 
> 
> > > Now from what I'm reading, it seams that the Dtrace layer may be
> > > abstracting out fields from the kernel. This is actually something I
> > > have been thinking about to solve the "tracepoint abi" issue. There's
> > > usually basic ideas that happen. An interrupt goes off, there's a
> > > handler, etc. We could abstract that out that we trace when an
> > > interrupt goes off and the handler happens, and record the vector
> > > number, and/or what device it was for. We have tracepoints in the
> > > kernel that do this, but they do depend a bit on the implementation.
> > > Now, if we could get a layer that abstracts this information away from
> > > the implementation, then I think that's a *good* thing.  
> > 
> > I don't like this deferred irq idea at all.
> 
> What do you mean deferred?

that's how I interpreted your proposal: 
"interrupt goes off and the handler happens, and record the vector number"
It's not a good thing to tell about irq later.
Just like saying lets record perf counter event and report it later.

> > Abstracting details from the users is _never_ a good idea.
> 
> Really? Most everything we do is to abstract details from the user. The
> key is to make the abstraction more meaningful than the raw data.
> 
> > A ton of people use bcc scripts and bpftrace because they want those details.
> > They need to know what kernel is doing to make better decisions.
> > Delaying irq record is the opposite.
> 
> I never said anything about delaying the record. Just getting the
> information that is needed.
> 
> > > 
> > > I wish that was totally true, but tracepoints *can* be an abi. I had
> > > code reverted because powertop required one to be a specific
> > > format. To this day, the wakeup event has a "success" field that
> > > writes in a hardcoded "1", because there's tools that depend on it,
> > > and they only work if there's a success field and the value is 1.  
> > 
> > I really think that you should put powertop nightmares to rest.
> > That was long ago. The kernel is different now.
> 
> Is it?
> 
> > Linus made it clear several times that it is ok to change _all_
> > tracepoints. Period. Some maintainers somehow still don't believe
> > that they can do it.
> 
> From what I remember him saying several times, is that you can change
> all tracepoints, but if it breaks a tool that is useful, then that
> change will get reverted. He will allow you to go and fix that tool and
> bring back the change (which was the solution to powertop).

my interpretation is different.
We changed tracepoints. It broke scripts. People changed scripts.

> 
> > 
> > Some tracepoints are used more than others and more people will
> > complain: "ohh I need to change my script" when that tracepoint
> > changes. But the kernel development is not going to be hampered by a
> > tracepoint. No matter how widespread its usage in scripts.
> 
> That's because we'll treat bpf (and Dtrace) scripts like modules (no
> abi), at least we better. But if there's a tool that doesn't use the
> script and reads the tracepoint directly via perf, then that's a
> different story.

absolutely not.
tracepoint is a tracepoint. It can change regardless of what
and how is using it.


  reply index

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 23:47 Kris Van Hees
2019-05-21 17:56 ` Alexei Starovoitov
2019-05-21 18:41   ` Kris Van Hees
2019-05-21 20:55     ` Alexei Starovoitov
2019-05-21 21:36       ` Steven Rostedt
2019-05-21 21:43         ` Alexei Starovoitov
2019-05-21 21:48           ` Steven Rostedt
2019-05-22  5:23             ` Kris Van Hees
2019-05-22 20:53               ` Alexei Starovoitov
2019-05-23  5:46                 ` Kris Van Hees
2019-05-23 21:13                   ` Alexei Starovoitov
2019-05-23 23:02                     ` Steven Rostedt
2019-05-24  0:31                       ` Alexei Starovoitov
2019-05-24  1:57                         ` Steven Rostedt
2019-05-24  2:08                           ` Alexei Starovoitov [this message]
2019-05-24  2:40                             ` Steven Rostedt
2019-05-24  5:26                             ` Kris Van Hees
2019-05-24  5:10                       ` Kris Van Hees
2019-05-24  4:05                     ` Kris Van Hees
2019-05-24 13:28                       ` Steven Rostedt
2019-05-21 21:36       ` Kris Van Hees
2019-05-21 23:26         ` Alexei Starovoitov
2019-05-22  4:12           ` Kris Van Hees
2019-05-22 20:16             ` Alexei Starovoitov
2019-05-23  5:16               ` Kris Van Hees
2019-05-23 20:28                 ` Alexei Starovoitov
2019-05-30 16:15                   ` Kris Van Hees
2019-05-31 15:25                     ` Chris Mason
2019-06-06 20:58                       ` Kris Van Hees
2019-06-18  1:25                   ` Kris Van Hees
2019-06-18  1:32                     ` Alexei Starovoitov
2019-06-18  1:54                       ` Kris Van Hees
2019-06-18  3:01                         ` Alexei Starovoitov
2019-06-18  3:19                           ` Kris Van Hees
2019-05-22 14:25   ` Peter Zijlstra
2019-05-22 18:22     ` Kris Van Hees
2019-05-22 19:55       ` Alexei Starovoitov
2019-05-22 20:20         ` David Miller
2019-05-23  5:19         ` Kris Van Hees
2019-05-24  7:27       ` Peter Zijlstra
2019-05-21 20:39 ` [RFC PATCH 01/11] bpf: context casting for tail call Kris Van Hees
2019-05-21 20:39 ` [RFC PATCH 02/11] bpf: add BPF_PROG_TYPE_DTRACE Kris Van Hees
2019-05-21 20:39 ` [RFC PATCH 03/11] bpf: export proto for bpf_perf_event_output helper Kris Van Hees
     [not found] ` <facilities>
2019-05-21 20:39   ` [RFC PATCH 04/11] trace: initial implementation of DTrace based on kernel Kris Van Hees
2019-05-21 20:39 ` [RFC PATCH 05/11] trace: update Kconfig and Makefile to include DTrace Kris Van Hees
     [not found] ` <features>
2019-05-21 20:39   ` [RFC PATCH 06/11] dtrace: tiny userspace tool to exercise DTrace support Kris Van Hees
2019-05-21 20:39 ` [RFC PATCH 07/11] bpf: implement writable buffers in contexts Kris Van Hees
2019-05-21 20:39 ` [RFC PATCH 08/11] perf: add perf_output_begin_forward_in_page Kris Van Hees
     [not found] ` <the>
     [not found]   ` <context>
2019-05-21 20:39     ` [RFC PATCH 09/11] bpf: mark helpers explicitly whether they may change Kris Van Hees
     [not found] ` <helpers>
2019-05-21 20:39   ` [RFC PATCH 10/11] bpf: add bpf_buffer_reserve and bpf_buffer_commit Kris Van Hees
2019-05-21 20:40 ` [RFC PATCH 11/11] dtrace: make use of writable buffers in BPF Kris Van Hees
2019-05-21 20:48 ` [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type implementation and sample use Kris Van Hees
2019-05-21 20:54   ` Steven Rostedt
2019-05-21 20:56   ` Alexei Starovoitov

Reply instructions:

You may reply publically 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=20190524020849.vxg3hqjtnhnicyzp@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=acme@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=kris.van.hees@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.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

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org bpf@archiver.kernel.org
	public-inbox-index bpf


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/ public-inbox