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
I can now scroll in chrome and not rage! It's like the laptop is 10x
Ran git blame, and found:
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
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