Quoting Chris Wilson (2018-03-26 20:52:06)
> Quoting Tvrtko Ursulin (2018-03-26 18:09:29)
> >
> > On 26/03/2018 12:50, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> > > b/drivers/gpu/drm/i915/i915_gem_context.h
> > > index 7854262ddfd9..74d4cadd729e 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > > @@ -150,6 +150,19 @@ struct i915_gem_context {
> > > */
> > > int priority;
> > >
> > > + /**
> > > + * @preempt_timeout: QoS guarantee for the high priority context
> > > + *
> > > + * Some clients need a guarantee that they will start executing
> > > + * within a certain window, even at the expense of others. This
> > > entails
> > > + * that if a preemption request is not honoured by the active
> > > context
> > > + * within the timeout, we will reset the GPU to evict the hog and
> > > + * run the high priority context instead.
> > > + *
> > > + * Timeout is stored in nanoseconds; exclusive max of 1s.
> >
> > Why did you think we would want to limit it to 1s?
>
> There's a realistic upper bound of hangcheck interval, say 6s. But
> that's completely internal and so irrelevant to the API. 1s was just in
> case we used any struct timespec and so could completely ignore the
> division, but it really stems from forgetting about ns_to_ktime()...
>
> Entirely arbitrary. I just couldn't believe setting a hrtimer for longer
> than smallval made sense, so plumped for something safe to fit in 32b.
Also it ties into using hrtimer instead of jiffies. My expectation was
that timeout would be on the order of a millisecond (on the high side);
if we are talking whole seconds we should switch to jiffies.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
