Quoting John Stultz (2017-08-25 23:57:04)
> In commit fc6eead7c1e2 ("time: Clean up CLOCK_MONOTONIC_RAW time
> handling"), I mistakenly added the following:
>
> /* Update the monotonic raw base */
> seconds = tk->raw_sec;
> nsec = (u32)(tk->tkr_raw.xtime_nsec >> tk->tkr_raw.shift);
> tk->tkr_raw.base = ns_to_ktime(seconds * NSEC_PER_SEC + nsec);
>
> Which adds the raw_sec value and the shifted down raw xtime_nsec
> to the base value.
>
> This is problematic as when calling ktime_get_raw(), we add the
> tk->tkr_raw.xtime_nsec and current offset, shift it down and add
> it to the raw base.
>
> This results in the shifted down tk->tkr_raw.xtime_nsec being
> added twice.
>
> My mistake, was that I was matching the monotonic base logic
> above:
>
> seconds = (u64)(tk->xtime_sec + tk->wall_to_monotonic.tv_sec);
> nsec = (u32) tk->wall_to_monotonic.tv_nsec;
> tk->tkr_mono.base = ns_to_ktime(seconds * NSEC_PER_SEC + nsec);
>
> Which adds the wall_to_monotonic.tv_nsec value, but not the
> tk->tkr_mono.xtime_nsec value to the base.
>
> The result of this is that ktime_get_raw() users (which are all
> internal users) see the raw time move faster then it should
> (the rate at which can vary with the current size of
> tkr_raw.xtime_nsec), which has resulted in at least problems
> with graphics rendering performance.
>
> To fix this, we simplify the tkr_raw.base accumulation to only
> accumulate the raw_sec portion, and do not include the
> tkr_raw.xtime_nsec portion, which will be added at read time.
This fixes our testcase of using ktime_get_raw() deltas. Thanks,
Tested-by: Chris Wilson <ch...@chris-wilson.co.uk>
-Chris
