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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
