Re: __i915_spin_request() sucks

From: Jens Axboe
Date: Thu Nov 12 2015 - 17:59:24 EST

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
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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at