Messages in this thread | | | Subject | Re: __i915_spin_request() sucks | From | Jens Axboe <> | Date | Thu, 12 Nov 2015 15:59:16 -0700 |
| |
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@chris-wilson.co.uk> >>>> 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
| |