Message-ID: <1339717084.13377.275.camel@gandalf.stny.rr.com>
Date:	Thu, 14 Jun 2012 19:38:04 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] tracing: Fix the outmost stupidity of tracing_off()

On Fri, 2012-06-15 at 00:50 +0200, Thomas Gleixner wrote:
> Steven,
> 
> On Fri, 15 Jun 2012, Thomas Gleixner wrote:
> >  void tracing_off(void)
> >  {
> >  	if (global_trace.buffer)
> > -		ring_buffer_record_on(global_trace.buffer);
> > +		ring_buffer_record_off(global_trace.buffer);
> 
> this is the gazillionst time that I wasted valuable time relying on
> the not so extraordinary expectation that the kernel tracer stays
> functional at least in the most basic ways.

I admit this bug should have never made it in. I'm not sure how it did
because I know I tested the tracing_off() code before submitting it. But
it could have been something stupid as making the fix but never pushing
it. There were some conflicts I had with updating to the latest tip and
I may not have checked that what made it into the tip repo was what was
in my latest.

That's not my normal workflow. I usually use git to make sure I can fast
forward all my changes to tip/perf/core, but it may have missed this
case.

> 
> I'm really tired of wasting hours and days just because you are unable
> to keep your stuff straight and functional.
> 
> I avoided to make public fuzz about that so far, but my patience is
> exhausted now.

I'm fine with you making your complaints public. I prefer it that way.
To get things out in the open, whether good or bad.

> 
> You know yourself how many times I ranted to you on IRC or in private
> conversations, but you just keep on to bask in your egocentric
> mastering the uber complexity treat.
> 
> Your self description (https://lwn.net/Articles/500388/):
> 
>  Complexity is my Sun, and I am the planet that orbits around it.

Actually, that saying was inspired by your previous comments to me.
Although, I didn't mean that to be that I like to do things in complex
ways, but that complex tasks seem to draw me in. There is a difference.



> 
> is pretty accurate.
> 
> You can orbit around whatever you want and as long as you want, just
> please do that on your own playground and not on the expense of
> others.

This isn't my own playground. That change happened to come about when
someone else started implementing using the ring buffer for something
completely different than tracing. I found that the tracing 'tracing_on'
file was interfering with that code. I had to make it so that the file
would only disable tracing, not all users of the ring buffer facility.

That's actually something I thought you would respect. As why would
echoing 0 into tracing_on for ftrace disable recording of data that has
nothing to do with tracing.

That file should have never been part of the ringbuffer, it should have
been contained by ftrace from day one. Yes, that was my own fault that I
did not do that.


> 
> I always held up to ftrace, but the repeating experience of
> disfunctionality caused by your refusal to put your priorites straight
> is just too annoying.
> 
> It's not the first time, that tracing_off() or other stuff I'm
> depending on has been broken and caused me exhaustive loss of time.

I remember the beginning with 'tracing_enabled' which was heavy weight
and required knowledge of the tracers. You hated it because this complex
tie in to the tracers made it difficult to stop and start tracing
between kernel and userspace. I agreed, and added the quick approach to
the ring buffer. But the ring buffer is generic, and that file should
have never been a big hammer to disable all ring buffer users. Just
ftrace's buffer.

> 
> I know that I'm not the average user of tracing, but that's not an
> excuse for pushing out crap over and over again.

I haven't used that excuse in a long time. Just when new code went in
and you were able to find all the corner cases. This bug was not a
corner case and I admit, this bug caused me a red face. When I saw it, I
really did crap. I said to myself, "I know I tested this, how the hell
did it get in like this??". I really think I pushed the wrong branch. As
I have used tracing_off() recently and it did work. But that was with my
own stale code. This failure was a hiccup in my work flow, and I have no
excuse for it.

> 
> I'm tired of it and to be honest, I'm going to spend some quality time
> on evaluating LLTNG. If it can do what I need then I switch over and
> see whether it can hold up to the basic expectations of a primary
> user. AFAICT from previous experience it can do that, and if Matthieu
> is willing and able to cooperate on integrating with perf, then I
> happily kick you off into your self chosen complexity orbit forever.

I'm all for competition. That's what open source is all about. If it
does come in and satisfies everyone's needs, I'll back off, and maybe
even contribute. In the past, I have tried to make contributions to
integrate perf and ftrace, but things did not go so well.

But a lot of my "complex" code gave perf the ability to do function
tracing. That was a lot of work and its main purpose was to give perf
that ability. With the integration of the libtraceevents library, things
are about to move faster as well.

I wanted to let perf have access to the ftrace ring buffering too, such
that we can get perf and ftrace events integrated. That was one of my
works in progress. We'll see how that goes.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists