On Fri, Jul 08, 2016 at 12:21:18PM +0300, Mika Kuoppala wrote:
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
>
> > In order to keep the memory allocated for requests reasonably tight, try
> > to reuse the oldest request (so long as it is completed and has no
> > external references) for the next allocation.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/i915_gem_request.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
> > index 9e9aa6b725f7..ee1189c35509 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -226,6 +226,13 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
> > if (ret)
> > return ret;
> >
> > + if (!list_empty(&engine->request_list)) {
> > + req = list_first_entry(&engine->request_list,
> > + typeof(*req), list);
> > + if (i915_gem_request_completed(req))
> > + i915_gem_request_retire(req);
> > + }
> > +
>
> With the last_submitted_seqno and req->seqno you could get rough
> estimation of requests-in-flight and perhaps retire handful more
> if the diff is very big?
That's the problem we want to avoid. We want to be cautious in how many
we retire as that leads to huge latency spikes here.
The observation that lead to trying to retire one was simply to improve
the slab-cache hit rate whilst minimising the time we spend in freeing
objects before submitting new work.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
