On Mon, Oct 20, 2008 at 1:10 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > I think it's a mistake for us to maintain a single clock for > gettimeofday() (well, "getnstimeofday" and the whole "clocksource_read()" > crud to be technically correct). And sure, I bet clocksource_read() can do > various per-CPU things and try to do that, but it's complex and pretty > generic code, and as far as I know none of the clocksources have even > tried. The TSC clocksource read certainly does not (it just does a very > similar horrible "at least don't go backwards" crud that the LTTng patch > suggested). > > So I think we should make "xtime" be a per-CPU thing, and add support for > per-CPU clocksources. And screw that insane "mark_tsc_unstable()" thing. > > And if we did it well, we migth be able to get good timestamps that way > too. Personally I'd been hoping that the experiments in the trace timestamping code would provide a safe area of experimentation before we adapt it to the TSC clocksource implementation for getnstimeofday(). Earlier I know Andi and Jiri were working on such a per-cpu TSC clocksource, but I don't know where it ended up. I'm not quite sure I followed your per-cpu xtime thoughts. Could you explain further your thinking as to why the entire timekeeping subsystem should be per-cpu instead of just keeping that back in the arch-specific clocksource implementation? In other words, why keep things synced at the nanosecond level instead of keeping the per-cpu TSC synched at the cycle level? thanks -john -- 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
