On 11/12/2015 03:52 PM, Jens Axboe wrote:
On 11/12/2015 03:19 PM, Chris Wilson wrote:
So today, I figured I'd try just killing that spin. If it fails, we'll
punt to normal completions, so easy change. And wow, MASSIVE
difference.
I can now scroll in chrome and not rage! It's like the laptop is 10x
faster now.
Ran git blame, and found:
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34
Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
and read the commit message. Doesn't sound that impressive. Especially
not for something that screws up interactive performance by a LOT.
What's the deal? Revert?
The tests that it improved the most were the latency sensitive tests and
since my Broadwell xps13 behaves itself, I'd like to understand how it
culminates in an interactivity loss.
1. Maybe it is the uninterruptible nature of the polling, making X's
SIGIO jerky:
This one still feels bad.
2. Or maybe it is increased mutex contention:
And so does this one... I had to manually apply hunks 2-3, and after
doing seat-of-the-pants testing for both variants, I confirmed with perf
that we're still seeing a ton of time in __i915_wait_request() for both
of them.
I don't see how #2 could make any difference, you're passing in 0x3 hard
coded for most call sites, so we poll. The ones that don't, pass a bool
(?!).
I should note that with the basic patch of just never spinning, I don't
see __i915_wait_request() in the profiles. At all.
--
Jens Axboe
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
