lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 1/3] Unified trace buffer


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


\
 
 \ /
  Last update: 2008-09-25 18:47    [W:0.177 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site