<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [SKL GT4e] large perf drop (up to 27%) in most 3D benchmarks" href="https://bugs.freedesktop.org/show_bug.cgi?id=111731#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [SKL GT4e] large perf drop (up to 27%) in most 3D benchmarks" href="https://bugs.freedesktop.org/show_bug.cgi?id=111731">bug 111731</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>(In reply to Eero Tamminen from <a href="show_bug.cgi?id=111731#c2">comment #2</a>) > (In reply to Chris Wilson from <a href="show_bug.cgi?id=111731#c1">comment #1</a>) > > drm/i915: Make i915_vma.flags atomic_t for mutex reduction > > drm/i915: Make shrink/unshrink be atomic > > > > are meh. > > > > drm/i915: Whitelist COMMON_SLICE_CHICKEN2 > > > > is a possiblity, but my money is on > > > > drm/i915: Force compilation with intel-iommu for CI validation > > > > A run with intel_iommu=off should test that theory, or intel_iommu=igfx_off > > and reverting HAX iommu/intel: Ignore igfx_off > > We run all tests currently with "intel_iommu=igfx_off" kernel command line > option, and while the author-date in above intel-iommu/igfx_off commits is > within range, their drm-tip repo commit dates are actually from Monday this > week, not from week ago? The commit is in core-for-CI which is a rebasing tree; on Monday it was rebased to v5.3 so that we could drop some patches. So the commit id will be updated fairly often while it remains in that branch. > (Why IOMMU perf impact would be SKL GT4e specific?) My guess at this moment would be that eDRAM feels the hit more significantly. Or that we've just got the caching completely wrong on that sku. > Also, whereas latest drm-tip kernel shows: > $ sudo grep mmu /sys/kernel/debug/dri/0/i915_capabilities > iommu: enabled > > There's no such output for the 2019-09-11 "b27acd37b7de" kernel where this > regression was noticed. That is a new feature added so that we could easily determine which machines in the farm have iommu enabled. > There is a difference on kernel IOMMU outputs between these commits though... > [snip] > After: > [ 0.632522] pci 0000:00:02.0: Adding to iommu group 1 So we definitely enabled iommu on igfx in this range. > PS. This regression is large enough that one run of CSDof is enough to see > whether kernel version is impacted: > ./synmark2 OglCSDof 20+% regression is also in line with some kbl (gt3e iirc) media runs I did.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>