Quoting Mika Kuoppala (2019-01-02 11:07:31) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > With kasan on a slow machine, it can take an age to check all the > > partial mappings in a single iteration, so break it up with a > > cond_resched) to avoid RCU stall reports. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/selftests/i915_gem_object.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c b/drivers/gpu/drm/i915/selftests/i915_gem_object.c > > index c3999dd2021e..be7ecb66ad11 100644 > > --- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c > > +++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c > > @@ -238,6 +238,7 @@ static int check_partial_mapping(struct drm_i915_gem_object *obj, > > u32 *cpu; > > > > GEM_BUG_ON(view.partial.size > nreal); > > + cond_resched(); > > Didn't get all the intricacies of rcu, but looks of it > this marks up the need of urgent quiescent state, even > if there is nothing to reschedule so should help for stall > reports. RCU is just the reporter of the stall in this case, it's just one of the hung task detectors. Think of this in terms of the soft NMI watchdog, we are inside the kernel for too long without giving userspace a chance (by calling schedule()). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
