Bug 35733

Lacking a piketon, I can't investigate immediately.

In the meantime, can you please gather a couple of cpu profiles using:

$ sudo perf record -f -g -a x11perf -aa10text -d :0

for the bad commit and without.

As the fix is a correctness/stability issue we can't simply revert it, but must instead understand why it impacts performance so and thence take mitigating steps.

Created attachment 44980 [details]
The perf.date for the bad commit f0c8602464

Created attachment 44981 [details]
The perf.data for the good commit 

This good commit is that the bad commit f0c860 which git revert the first bad commit d4aeee

*grin*

And now can you do "perf report -i perf.data.[good|bad] | head -150" :)

You will need the sources for each kernel build available (iirc).

perf does report a big spike in kernel time, so it should provide some useful information once we marry it to some symbols.

head -150 might not be enough. Try head -1500 instead.

Created attachment 44983 [details]
The perf.data.bad which head -1500

Created attachment 44985 [details]
The perf.data.good which head -1500

Bah, bad symbol data. But my interpretation is that it is indeed just due to hitting a page-fault and having to fallback to the relocation slow-path - note the appearance of vmalloc/rb_next in the profile.

I have curbed the number of relocations required by the ddx, but I know where I can find many more...

(In reply to comment #8)
> Bah, bad symbol data.
Do you mean you can't open my attachment(id=44983) or some other?

Just that the symbols perf used for the i915.ko addresses are garbage. However, I can guess what they should have been judging by the delta elsewhere.

Created attachment 44988 [details] [review]
Retire requests before disabling pagefaults

This is not the ultimate patch, but it may help reduce the number of unnecessary fallbacks.

Created attachment 44989 [details] [review]
An ugly hack

These should recover the performance, but only as an absolute last resort.

If it is not clear, please try the first patch first by itself. The second patch is just in case the first is not enough and to prove that the relocation on an active bo is the cause.

*** Bug 35761 has been marked as a duplicate of this bug. ***

Sorry,but I think the bug still exists.Testing in commit f0c8602,performance for x11perf -aa10text,compare with good commit(979k):
no patch:          426k
patch(44988) only: 432k
both(44988,44988): 391k

I just noticed this bisected patch is on -backport branch, so I'd put it into P1.

No, it is not a P1 bug. The P1 bug is the OOPS that this fixes.

Pushed what should be a couple of mitigating patches to xf86-video-intel. Please compare.

(In reply to comment #18)
> Pushed what should be a couple of mitigating patches to xf86-video-intel.
> Please compare.

Wiht the xf86 2.14.902-28-g47462f65e90e49e5ffd48c77c4f95255b9573f83, 
2D performance:
rgb10text:1060k
aa10text:1380k

(In reply to comment #18)
> Pushed what should be a couple of mitigating patches to xf86-video-intel.
> Please compare.
Compare commit 5f31025cce with the commit 47462f6 in xf86:
rgb10text:522k  1060k
aa10text: 552k  1380k

The 2D performance downgraded again after we git revert commit 59ed6b05db on xf86-video-intel.

Not unexpected, but still :(

We wait for sna.

Fixed in SNA.

Verified it.

Closing old verified.