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

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

On Thu, 25 Sep 2008, Ingo Molnar wrote:
>
> ... which is exactly what sched_clock() does, combined with a 
> multiplication. (which is about as expensive as normal linear 
> arithmetics on most CPUs - i.e. in the 1 cycle range)

First off, that's simply not true.

Yes, it happens to be true on modern x86-64 CPU's. But in very few other 
places. Doing even just 64-bit multiples is _expensive_. It's not even 
_near_ single-cycle.

But more importantly:

> Normalizing has the advantage that we dont have to worry about it ever 
> again. Not about a changing scale due to cpufreq, slowing down or 
> speeding up TSCs due to C2/C3. We have so much TSC breakage all across 
> the spectrum that post-processing it is a nightmare in practice.

Total and utter bullshit, all of it.

Have you forgotten all the oopses due to divide-by-zero because 
sched_clock() was called early? All that early code that we might well 
want to trace through?

Not only that, but have you forgotten about FTRACE and -pg? Which means 
that every single C function calls into tracing code, and that can 
basically only be disabled on a per-file basis? 

As for C2/C3 - that's just an argument for *not* doing anything at trace 
time. What do you think happens when you try to trace through those 
things? You're much better off trying to sort out the problems later, when 
you don't hold critical locks and are possibly deep down in some buggy 
ACPI code, and you're trying to trace it exactly _because_ it is buggy.

The thing is, the trace timestamp generation should be at least capable of 
being just a couple of versions of assembly language. If you cannot write 
it in asm, you lose. You cannot (and MUST NOT) use things like a 
virtualized TSC by mistake. If the CPU doesn't natively support 'rdtsc' in 
hardware on x86, for example, you have to have another function altogether 
for the trace timestamp.

And no way in hell do we want to call complex indirection chains that take 
us all over the map and have fragile dependencies that we have already hit 
several times wrt things like cpufreq.

WE ARE MUCH BETTER OFF WITH EVEN _INCORRECT_ TIME THAN WE ARE WITH FRAGILE 
TRACE INFRASTUCTURE.

> Plus we want sched_clock() to be fast anyway.

Yeah. And we want system calls to be _really_ fast, because they are even 
more critical than the scheduler. So maybe we can use a "gettime()" system 
call.

IOW, your argument is a non-argument. No way in HELL do we want to mix up 
sched_clock() in tracing. Quite the reverse. We want to have the ability 
to trace _into_ sched_clock() and never even have to think about it!

TSC is not pefect, but (a) it's getting better (as you yourself point 
out), and in fact most other architectures already have the better 
version. And (b) it's the kind of simplicity that we absolutely want.

Do you realize, for example, that a lot of architectures really only have 
a 32-bit TSC, and they have to emulate a 64-bit one (in addition to 
conveting it to nanoseconds using divides) for the sched_clock()? They'd 
almost certainly be much better off able to just use their native one 
directly.

Yeah, it would probably cause some code duplication, but the low-leel 
trace infrastructure really is special. It can't afford to call other 
subsystems helper functions, because people want to trace _those_.

				Linus