> On Sep 27, 2018, at 7:36 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > >> On Wed, 19 Sep 2018, Thomas Gleixner wrote: >> On Tue, 18 Sep 2018, Andy Lutomirski wrote: >>>> On Sep 18, 2018, at 3:46 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >>>>> On Tue, 18 Sep 2018, Andy Lutomirski wrote: >>>>> Do we do better if we use signed arithmetic for the whole calculation? >>>>> Then a small backwards movement would result in a small backwards result. >>>>> Or we could offset everything so that we’d have to go back several >>>>> hundred ms before we cross zero. >>>> >>>> That would be probably the better solution as signed math would be >>>> problematic when the resulting ns value becomes negative. As the delta is >>>> really small, otherwise the TSC sync check would have caught it, the caller >>>> should never be able to observe time going backwards. >>>> >>>> I'll have a look into that. It needs some thought vs. the fractional part >>>> of the base time, but it should be not rocket science to get that >>>> correct. Famous last words... >>>> >>> >>> It’s also fiddly to tune. If you offset it too much, then the fancy >>> divide-by-repeated-subtraction loop will hurt more than the comparison to >>> last. >> >> Not really. It's sufficient to offset it by at max. 1000 cycles or so. That >> won't hurt the magic loop, but it will definitely cover that slight offset >> case. > > I got it working, but first of all the gain is close to 0. > > There is this other subtle issue that we've seen TSCs slowly drifting apart > which is caught by the TSC watchdog eventually, but if it exeeds the offset > _before_ the watchdog triggers, we're back to square one. > > So I rather stay on the safe side and just accept that we have to deal with > that. Sigh. > > Seems okay to me. Oh well. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
