[Bug 102336] [BYT] Offscreen tests performance drops to <1/3 due to power management

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=102336

--- Comment #6 from Chris Wilson <chris at chris-wilson.co.uk> ---
Swapped out the revert for commit 177776dba04e4e02d46ec46d7927580eaeb106b6
Author: John Stultz <john.stultz at linaro.org>
Date:   Fri Aug 25 15:57:04 2017 -0700

    time: Fix ktime_get_raw() issues caused by incorrect base accumulation

    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.

in topic/core-for-CI

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170826/f04a5ee4/attachment.html>