On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Some persistent clocksources can be on a slow external bus. For shorter > latencies for RT use, let's allow toggling the clocksource during idle > between a faster non-persistent runtime clocksource and a slower persistent > clocksource. So yea, as Thomas mentioned, this will cause problems for timekeeping accuracy, since we end up resetting the ntp state when we change clocksource (additionally you gain a bit of error each time you switch clocksources). So you'll most likely see trouble w/ ntpd steering the clock. I'm not sure its quite clear in the description as to the need here. Could you expand a bit as to the rational for why? I assume it has to do with you have a high-res clocksource that is good for fine-grained clock_gettime() calls, but wraps quickly, making it poor for long idle times. So you're trying to swap to a less fine grained clocksource that won't wrap so fast? The persistent-clock-like name muddies things further, since the persistent-clock is used for suspend, while it looks like this is just for idle times. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
