Messages in this thread | | | From | Chris Wilson <> | Subject | Re: [RFC][PATCH] time: Fix ktime_get_raw() issues caused by incorrect base accumulation | Date | Sat, 26 Aug 2017 11:20:41 +0100 |
| |
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 <chris@chris-wilson.co.uk> -Chris
| |