[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply a cond_resched() to the saturated signaler (rev2)

[Chris Wilson]

On Tue, Apr 04, 2017 at 12:24:15PM -0000, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Apply a cond_resched() to the saturated signaler (rev2)
> URL   : https://patchwork.freedesktop.org/series/22418/
> State : success
> 
> == Summary ==
> 
> Series 22418v2 drm/i915: Apply a cond_resched() to the saturated signaler
> https://patchwork.freedesktop.org/api/1.0/series/22418/revisions/2/mbox/
> 
> Test gem_exec_flush:
>         Subgroup basic-batch-kernel-default-uc:
>                 fail       -> PASS       (fi-snb-2600) fdo#100007
> Test gem_exec_suspend:
>         Subgroup basic-s4-devices:
>                 pass       -> DMESG-WARN (fi-kbl-7560u) fdo#100125
>                 pass       -> DMESG-WARN (fi-bxt-t5700) fdo#100125
> Test kms_cursor_legacy:
>         Subgroup basic-busy-flip-before-cursor-legacy:
>                 fail       -> PASS       (fi-snb-2600)
> 
> fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

Unrelated.

>From the aether, Tvrtko wrote:
> My thinking was to add a check before the request assignment like:
> 
> 	rcu_read_lock();
> 	request = ...;
> 	if (request && !need_resched())
> 		request = ...;
> 	else
> 		request = NULL;
> 	rcu_read_unlock();
> 
> But this looks correct as well, maybe it is just my preference on what 
> would have been easier to understand.

This has the danger of missing a wake-up reason. After setting
TASK_INTERRUPTIBLE, we must then check all the possible wake-up sources
before calling schedule, or else we risk another kthread_park() style
bug.

Thanks for the review and digging through the cond_resched() mystery.
Pushed,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre