Re: [PATCH 1/2] ftrace: single CPU tracers use CPU clock

[Steven Rostedt]

On Sat, 26 Jul 2008, Ingo Molnar wrote:
>
> so it's off by 60 usecs. That matters to the chronology of SMP events,
> and to the irqsoff and preemptoff tracers - if we update the clock
> incorrectly - i.e. if we modify the clock across CPUs so that a running
> CPU can see an 'involuntary' jump in local time.

Usually the jump is caused by the clock getting too far away from the
gtod clock. The way the current code works is to look at the gtod at every
tick and also record the TSC and jiffies.  When we read the cpu_clock, it
reads the TSC, calculates the delta from the last read (may be from the
tick if it is the first read since tick), and adds the delta to the clock.
To handle strange behaviours with TSC, if the TSC is too big we do not add
the full delta but instead put the clock to the max allowable, or if we are
already greater than or equal to the max, just add one nanosecond.

This causes some strange behaviour with the traces.


>
> that should be fixed then - and all tracers (and the scheduler) will
> improve - instead of having this special-case.

I added a multiplier to the tsc delta to try to keep it close to the gtod
clock. But there's still issues. No multiplier is perfect and we still
have drifts. The gtod itself is affected by the NTP and changes as well.


Two TSCs with different freqs on the same box will have an inaccuracy.
This is a very difficult problem to solve, and I'm not sure we can do much
better than the 60 microseconds that we currently have.

Even with insync TSCs, we see that the comparison to the GTOD causes
jumps, due to drifts between the two clocks.

I still like to have the special cases for the per CPU tracers. We can get
rid of it when (if) we fix the issues for the other tracers. Not adding
the special case for those tracers wont make us work faster on this
problem. But it will keep people from using those tracers because the
results will be meaningless.


-- Steve

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