Re: [Ksummit-discuss] [TECH TOPIC] Pulling away from the tracing ABI quicksands

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, Jun 29, 2017 at 6:16 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I didn't realize you even used the tracepoints.

I don't.

But I absolutely refuse to see this kind of idiotic churn, and even
more the idiotic "let's discuss it at ksummit" when we've had those
tracing discussions for years and they apparently didn't result in
anything workable.

Dammit, this stupid tracing issue really has been discussed for too
long, and the answer hasn't changed. You can have a static tracepoint,
but only for GENERIC stuff. Not random internal stuff that only makes
sense to one scheduler implementation. We've made that mistake too
many times before, we're not making it again.

Didn't that useless 'prio' field teach you anything? Instead, now you
want to add new fields that are not generic, but specific to one very
particular scheduling class. EXACTLTY like "prio" was/is.

> You mean kprobes? Or perhaps eBPF?
>
> The information about SCHED_DEADLINE is not trivial enough to extract
> with them.

You clearly shouldn't extract it unless you are a scheduler developer,
and then you can damn well instrument that thing yourself with your
own private tracepoints that you don't try to claim are generic and
useful to anybody else.

> Well, the world does have people that use tools besides powertop.

I said "like powertop".

I did not say "only powertop".

The fact is, no generic scheduler tracing tool that is run by real
people is ever going to care about some esoteric field that isn't even
relevant to most schedulers out there.

> Just one last note. I've tried very hard to keep tracing as contained
> as possible. That is, not to let implementation details and such creep
> into the rest of the kernel.

Yeah, and apparently it was a complete failure, if extending a single
breakpoint isn't possible without breaking stuff, and if people STILL
talk about the idiotic "oh, but it has that argument that doesn't make
sense" issue.

And dammit, having that same stupid argument _again_ isn't going to
improve things.

Why can't you just attach some eBPF script to the one tracepoint you
already have? I know that has been at least discussed, and it seems to
be the only reasonable way forward, since the existing thing clearly
isn't working.

                  Linus