[Bug 108700] 2x Media CPU power usage, or 15% perf drop when CPU bound GPU use-case is TDP limited

[bugzilla-daemon at freedesktop.org]

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

--- Comment #14 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Eero Tamminen from comment #8)
> STIBP fixes in drm-tip v4.20-rc5 fix the CPU bound 3D cases performance
> (test-case 1).
> 
> However, those fixes, nor disabling Spectre mitigation completely from
> kernel command line (checked by David), do NOT have any impact on the Media
> performance regression (test-case 2).

After above, regressed Media tests-case "perf" started to fluctuate between the
original and regressed performance.

In start of January "perf" stopped fluctuating:
* KBL GT3e - perf keeps at what it was before regression
* SKL GT4e - perf keeps in regressed state

At start of February, KBL GT3e "perf" dropped to lower than it was before,
while SKL GT4e perf remained at January level.  HOWEVER, that was because of:

(In reply to Eero Tamminen from comment #12)
> Note: kernel had been scheduling parallel media processes very badly/unevenly
> (I think most visible on GT4e SkullCanyon).  This appears to have been fixed
> somewhere in early February (and AFAIK didn't happen earlier in 2018). If
> one just sums FPS reported by the individual processes together (like is
> suggested in first comment use-case), not fully parallel scheduling could
> distort the results significantly.

I.e. this issue could actually have been result of kernel messing up media
thread scheduling, and that being hidden by the STIBP mess, but I don't have
data when the media thread scheduling actually broke, so maybe we'll just
forget about this bug?  => WONTFIX/WORKSFORME?

(I've of course fixed perf measuring to be less impacted by broken scheduling,
but I'm not going to track down when it changed, as I can't easily automate its
bisecting, and it works OK now. If somebody else is interested to do that, I
can help with the test-cases though.)

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