[Bug 111731] [SKL GT4e] large perf drop (up to 27%) in most 3D benchmarks
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Wed Sep 18 13:04:31 UTC 2019
https://bugs.freedesktop.org/show_bug.cgi?id=111731
--- Comment #3 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to Eero Tamminen from comment #2)
> (In reply to Chris Wilson from comment #1)
> > 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.
--
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/20190918/2b7d2428/attachment.html>
More information about the intel-gfx-bugs
mailing list