[Intel-gfx] [PATCH 31/38] drm/i915: Track the pinned kernel contexts on each engine
Chris Wilson
chris at chris-wilson.co.uk
Tue Mar 5 19:26:08 UTC 2019
Quoting Tvrtko Ursulin (2019-03-05 18:17:35)
>
> On 05/03/2019 18:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-05 18:07:39)
> >>> /*
> >>> * Similarly the preempt context must always be available so that
> >>> - * we can interrupt the engine at any time.
> >>> + * we can interrupt the engine at any time. However, as preemption
> >>> + * is optional, we allow it to fail.
> >>> */
> >>> - if (i915->preempt_context) {
> >>> - ce = intel_context_pin(i915->preempt_context, engine);
> >>> - if (IS_ERR(ce)) {
> >>> - ret = PTR_ERR(ce);
> >>> - goto err_unpin_kernel;
> >>> - }
> >>> - }
> >>> + if (i915->preempt_context)
> >>> + pin_context(i915->preempt_context, engine,
> >>> + &engine->preempt_context);
> >>
> >> You lost the failure path here. I suspect deliberately? But I am not
> >> convinced we want to silently lose preemption when keeping the failure
> >> path is so easy.
> >
> > The failure path kills the module. Whereas we can quite happily survive
> > without preemption.
>
> Yes it is hard to decide what is worse, modprobe failure which never
> happens, or change in performance profile which also never happens. :)
>
> For something so unlikely I'd rather see it fail than silently change
> behaviour. Perhaps it has some relevance during development and platform
> bringup if nowhere else.
I err on the opposite side, keep going at all costs so that the user
isn't scaring at a blank screen of doom. It's not exactly a silent
failure, we tell anyone who asks that preemption is enabled :)
-Chris
More information about the Intel-gfx
mailing list