Messages in this thread | | | From | "Luck, Tony" <> | Date | Mon, 20 Oct 2008 11:07:05 -0700 | Subject | RE: [RFC patch 15/15] LTTng timestamp x86 |
| |
> And what do we say when we detect this ? "sorry, please upgrade your > hardware to get a reliable trace" ? ;)
My employer might be happy with that answer ;-) ... but I think we could tell the user to:
1) adjust something in /sys/... 2) boot with some special option 3) rebuild kernel with CONFIG_INSANE_TSC=y
to switch over to a heavyweight workaround in s/w. Systems that require this are already in the minority ... and I think (hope!) that current and future generations of cpus won't have these challenges.
So this is mostly a campaign for the default code path to be based on current (sane) TSC behaviour ... with the workarounds for past problems kept to one side.
> Nope, this is not required. I removed the heartbeat event from LTTng two > weeks ago, implementing detection of the delta from the last timestamp > written into the trace. If we detect that the new timestamp is too far > from the previous one, we write the full 64 bits TSC in an extended > event header. Therefore, we have no dependency on interrupt latency to > get a sane time-base.
Neat. Could you grab the HPET value here too?
> (8 cores up)
Interesting results. I'm not at all sure why HPET scales so badly. Maybe some h/w throttling/synchronizing going on???
-Tony
| |