On Thu, Dec 1, 2016 at 12:46 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > On Thu, 1 Dec 2016, John Stultz wrote: >> I would also suggest: >> 3) If the systems are halted for longer then the timekeeping core >> expects, the system will "miss" or "lose" some portion of that halted >> time, but otherwise the system will function properly. Which is the >> result with this patch. > > Wrong. This is not the result with this patch. > > If the time advances enough to overflow the unsigned mult, which is > entirely possible as it takes just twice the time of the negative overflow, > then time will go backwards again and that's not 'miss' or 'lose', that's > just broken. Eh? If you overflow the 64bits on the mult, the shift (which is likely large if you're actually hitting the overflow) brings the value back down to a smaller value. Time doesn't go backwards, its just smaller then it ought to be (since the high bits were lost). > If we want to prevent that, then we either have to clamp the delta value, > which is the worst choice or use 128bit math to avoid the overflow. I'm not convinced yet either of these approaches are really needed. >> I'm not sure if its really worth trying to recover that time or be >> perfect in those situations. Especially since on narrow clocksources >> you'll have the same result. > > We can deal with the 64bit overflow at least for wide clocksources which > all virtualizaton infected architectures provide in a sane way. Another approach would be to push back on the virtualization environments to step in and virtualize a solution if they've idled a host for too long. They could do like the old tick-based virtualization environments used to and trigger a few timer interrupts while slowly removing a fake negative clocksource offset to allow time to catch up more normally after a long stall. Or they could require clocksources that have smaller shift values to allow longer idle periods. > For bare metal systems with narrow clocksources the whole issue is non > existant we can make the 128bit math depend on both a config switch and a > static key, so bare metal will not have to take the burden. Bare metal machines also sometimes run virtualization. I'm not sure the two are usefully exclusive. thanks -john -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html