Hi Pavel, On Wed, May 08, 2013 at 12:55:42PM +0200, Pavel Machek wrote: > Hi! > > > > > Sorry. You seem to not like the merged change, but I guess I'm not > > > > quite sure what exactly your objection is here. > > > > > > I'm not exactly sure what my objections are. > > > > > > TSC was not designed for long-term precise timekeeping. [...] > > > > The TSC is just a 64-bit counter that can be read very cheaply. > > > > If the TSC is _implemented_ precisely in hardware and is kept in sync over > > CPUs then it's obviously fit for long-term precise timekeeping from that > > point on. > > Yes. But the clock for TSC is not being generated in CPU (right?) and > AFAICT, the code said "if the CPU is new enough, assume TSC is good > timesource". You need good clock for good timesource. > > > > [...] but some people suspend their machines for longer than that. Plus > > > I wonder how it will interfere with /etc/adjtime. > > > > If it's precise then why should it interfere? > > > > The history of the TSC being problematic can be ignored the moment CPU > > makers fix it completely - and apparently that is happening... > > AFAICT we normally use RTC/PIT during runtime.
This is not true. AFAIK, most modern X86 processors used by Laptop/Desktop/Servers/Smartphone is not using PIT as the runtime clocksource. If you check the Linux laptop/desktop you are using, most probably it is using TSC as clocksource, less likely the "hpet", and not likey the "pit". Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
