> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
