Message-ID: <20181213003938.GD24195@altlinux.org>
Date:   Thu, 13 Dec 2018 03:39:38 +0300
From:   "Dmitry V. Levin" <ldv@...linux.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>, Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Luis Claudio R. Goncalves" <lclaudio@...g.org>,
        Eugene Syromyatnikov <esyr@...hat.com>,
        Frederic Weisbecker <fweisbec@...il.com>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

Hi Peter,

On Mon, Dec 10, 2018 at 11:18:18AM +0100, Peter Zijlstra wrote:
> On Sat, Dec 08, 2018 at 12:38:05PM -0500, Steven Rostedt wrote:
> > On Sat, 8 Dec 2018 11:44:23 +0100, Peter Zijlstra wrote:
> 
> > > > Why do we care about lost events? Because strace records *all* events,
> > > > as that's what it does and that's what it always has done. It would be
> > > > a break in functionality (a regression) if it were to start losing
> > > > events. I use strace to see everything that an application is doing.  
> > > 
> > > So make a new tool; break the expectation of all events. See if there's
> > > anybody that really cares.
> > 
> > Basically you are saying, break strace and see if anyone notices?
> 
> Nah, give it a new name. Clearly mark this is a new tool.
> 
> > > > When we discussed this at plumbers, Oracle people came to me and said
> > > > how awesome it would be to run strace against their database accesses.
> > > > The problem today is that strace causes such a large overhead that it
> > > > isn't feasible to trace any high speed applications, especially if
> > > > there are time restraints involved.  
> > > 
> > > So have them run that perf thing acme pointed to.
> > > 
> > > So far nobody's made a good argument for why we cannot have LOST events.
> > 
> > If you don't see the use case, I'm not sure anyone can convince you.
> > Again, I like the fact that when I do a strace of an application I know
> > that all system calls that the application I'm tracing is recorded. I
> > don't need to worry about what happened in the "lost events" space.
> 
> You're the one pushing for this crap without _any_ justification. Why
> are you getting upset if I ask for some?
> 
> If people care so much, it shouldn't be hard to write up a coherent
> story on this, so far all I seem to get is: because it's always been
> like that.
> 
> Which really isn't much of an argument.

As you rightly pointed out, strace users are expecting that no events are
lost because it's always been like that, and it would require some efforts
to imagine what kind of things are going to break if this is no longer the
case.

Last FOSDEM I attended a talk [1] by Philippe Ombredanne, he was speaking
about a strace-based tool called TraceCode that constructs build graphs
that are used to find out "exactly which files were built, by what and how
they were transformed in multiple steps from sources to your final binaries".

Imagine you told Philippe that strace now works faster but it's no longer
reliable because some events may be lost, and he would have to repeat
builds under strace again and again until he is lucky.  I can imagine his
reaction to this piece of news, and I certainly wouldn't like to be the
messenger.

btw, I didn't ask for the implementation to be ugly.
You don't have to introduce polling into the kernel if you don't want to,
userspace is perfectly capable of invoking wait4(2) in a loop.
Just block the tracee, notify the tracer, and let it pick up the pieces.

[1] https://archive.fosdem.org/2018/schedule/event/debugging_tools_stracing_build/


-- 
ldv

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists