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

[Martin Bligh]

>  - save a GTOD+TSC pair at important events, such as to-idle and
>   from-idle, and in the periodic sched_tick(). [ perhaps also save it
>   when we change cpufreq. ]

We did GTOD, but I think it's a bad idea, because NTP moves it.

>  - save the (last_GTOD, _relative_-TSC) pair in the trace entry
>
> with that we have a chance to do good post-processed correlation - at
> the cost of having 12-16 bytes of timestamp, per trace entry.
>
> Or we could upscale the GTOD to 'TSC time', at go-idle and from-idle.
> Which is rather complicated with cpufreq - which frequency do we want to
> upscale to if we have a box with three available frequencies? We could
> ignore cpufreq altogether - but then there goes dependable tracing on
> another range of boxes.

Simple solution: turn off cpufreq whilst tracing is on ;-)

Harder: Keep a timebase and frequency divisor on a per-cpu basis
and calculate your offsets from there. This brings you down to
HPET resolution though
--
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/