All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: "Qais Yousef" <qais.yousef@arm.com>,
	"Valentin Schneider" <valentin.schneider@arm.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Jirka Hladký" <jhladky@redhat.com>,
	"Jiří Vozár" <jvozar@redhat.com>, "X86 ML" <x86@kernel.org>
Subject: Re: [PATCH 2/2] sched/debug: add sched_update_nr_running tracepoint
Date: Wed, 4 Sep 2019 08:51:21 -0700	[thread overview]
Message-ID: <CAADnVQK+bSzFdZmgTnDSgibhJ81pR19P6hFArqmZa_xKA1r1VQ@mail.gmail.com> (raw)
In-Reply-To: <20190904154000.GJ240514@google.com>

On Wed, Sep 4, 2019 at 8:40 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> On Wed, Sep 04, 2019 at 08:25:27AM -0700, Alexei Starovoitov wrote:
> > On Wed, Sep 4, 2019 at 6:10 AM Joel Fernandes <joel@joelfernandes.org> wrote:
> > >
> > > I wonder if this distinction of "tracepoint" being non-ABI can be documented
> > > somewhere. I would be happy to do that if there is a place for the same. I
> > > really want some general "policy" in the kernel on where we draw a line in
> > > the sand with respect to tracepoints and ABI :).
> >
> > It's been discussed millions times. tracepoints are not abi.
> > Example: android folks started abusing tracepoints inside bpf core
> > and we _deleted_ them.
>
> This is news to me, which ones?

those that your android teammates abused!

> > Same thing can be done with _any_ tracepoint.
> > Do not abuse them and stop the fud about abi.
>
> I don't know what FUD you are referring to. At least it is not coming from
> me. This thread is dealing with the issue about ABI specifically, I jumped in
> just now. As I was saying earlier, I don't have a strong opinion about this.
> I just want to know what is the agreed upon approach so that we can stick to
> it.
>
> It sounds like the agreement here is tracepoints can be added and used
> without ABI guarantees, however the same is not true with trace events.
> Where's the FUD in that?

Anything in tracing can be deleted.
Tracing is about debugging and introspection.
When underlying kernel code changes the introspection points change as well.

  reply	other threads:[~2019-09-04 15:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 15:43 [PATCH 0/2] sched/debug: add sched_update_nr_running tracepoint Radim Krčmář
2019-09-03 15:43 ` [PATCH 1/2] x86/mm/tlb: include tracepoints from tlb.c instead of mmu_context.h Radim Krčmář
2019-09-03 15:43 ` [PATCH 2/2] sched/debug: add sched_update_nr_running tracepoint Radim Krčmář
2019-09-03 16:05   ` Valentin Schneider
2019-09-04  4:23     ` Joel Fernandes
2019-09-04  8:14       ` Peter Zijlstra
2019-09-04 10:52         ` Qais Yousef
2019-09-04 13:11         ` Joel Fernandes
2019-09-04 15:26           ` Alexei Starovoitov
2019-09-04 15:33             ` Joel Fernandes
2019-09-04 15:37               ` Alexei Starovoitov
2019-09-04 15:41                 ` Joel Fernandes
2019-09-04 10:43       ` Qais Yousef
2019-09-04 13:06         ` Joel Fernandes
2019-09-04 14:20           ` Qais Yousef
2019-09-04 14:41             ` Joel Fernandes
2019-09-04 14:57               ` Qais Yousef
2019-09-04 15:46                 ` Joel Fernandes
2019-09-04 15:25           ` Alexei Starovoitov
2019-09-04 15:40             ` Joel Fernandes
2019-09-04 15:51               ` Alexei Starovoitov [this message]
2019-09-04 17:47                 ` Peter Zijlstra
2019-09-04 17:53                   ` Alexei Starovoitov
2019-09-05  8:13                     ` Ingo Molnar
2019-09-05 16:49                       ` Alexei Starovoitov
2019-09-04  6:55     ` chengjian (D)
2019-09-04 13:13   ` Peter Zijlstra
2019-09-04 13:21     ` Valentin Schneider
2019-09-04 14:37   ` Qais Yousef
2019-09-04 17:48     ` Peter Zijlstra
2019-09-09 10:59       ` Qais Yousef

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=CAADnVQK+bSzFdZmgTnDSgibhJ81pR19P6hFArqmZa_xKA1r1VQ@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jhladky@redhat.com \
    --cc=joel@joelfernandes.org \
    --cc=jvozar@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=rkrcmar@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.com \
    --cc=x86@kernel.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.