Re: [RFC PATCH 1/3] Unified trace buffer

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 25 Sep 2008, Linus Torvalds wrote:
> > 
> > You also ignore the early trace issues, and have apparently not used 
> > it for FTRACE. You also ignore the fact that without TSC, it goes 
> > into the same "crap mode" that is appropriate for the scheduler, but 
> > totally useless for tracing.
> 
> Oh, and I didn't notice (because Steven pointed out "notrace" and I 
> didn't see any of them), that in order to get things to work you had 
> just added
> 
> CFLAGS_REMOVE_lockdep.o = -pg
> CFLAGS_REMOVE_lockdep_proc.o = -pg
> CFLAGS_REMOVE_mutex-debug.o = -pg
> CFLAGS_REMOVE_rtmutex-debug.o = -pg
> CFLAGS_REMOVE_cgroup-debug.o = -pg
> CFLAGS_REMOVE_sched_clock.o = -pg
> CFLAGS_REMOVE_sched.o = -mno-spe -pg
> 
> all ovr the place, which was part of my argument against this crap in 
> the first place.

Really, we traced all these files for ages. I can restore it if it's 
worthwile - but lockdep totally kills the usability of function traces, 
it inserts thousands of uninteresting events over and over again.

Note commit c349e0a0, there i added -no-pg for robustness reasons (we 
locked up) - back then the scheduler clock was within sched.c. Now it is 
all separated out cleanly in kernel/sched_clock.o and i think we can add 
-pg to sched.o again and trace it.

> Yes, by using all that common infrastructure, you can share some code, 
> but you will always hit that case that now you have serious issues 
> with actually marking it. Now the tracer has to have recursion 
> detection if you ever want to trace any function that might be used 
> for the clock - and quite frankly, especially with virtualization, 
> it's not AT ALL obvious what those are all the time..

yes, that's true. And that's why we absolutely want to have recursion 
detection anyway - even given ftrace's _totally_ conservative design 
it's _very_ easy to accidentally recurse somewhere.

ftrace has the same robustness design as lockdep has: as little external 
infrastructure dependencies as possible. And lockdep has recursion 
checks too, and excessive amounts of paranoia all around the place.

Ftrace has the same robustness philosophy too, and yes, despite that we 
judged cpu_clock() to be worth the risk, because accurate and fast 
timestamps are a feature and we didnt want to duplicate.

If then i'd rather move towards simplifying sched_clock() even more - 
that's important for the scheduler too. The scheduler clock has _very_ 
similar requirements to the tracer clock.

> That is exactly one of the examples I gave for _not_ doing this. Go 
> back and read my previous emails. Rather than talking about how I call 
> your arguments BS without saying why.

we lived with these kinds of complications for years literally, and i'm 
not that stupid to not simplify a debugging framework when i can do it - 
and i'd not mind risk reduction. Paravirt is hugely misdesigned piece of 
PITA, for basically every piece of infrastructure that we have: locking, 
GTOD, lockdep, and yes, the tracer too.

So ... if you could suggest a method of how we could get good timestamps 
in a post-processed method with TSC timestamps, that would be great. 
That would solve all this discussion and i'm not going to argue against 
saving raw TSC timestamps, as they _are_ simpler and more robust.

	Ingo