Quoting Tvrtko Ursulin (2018-01-17 10:18:38)
>
> On 16/01/2018 17:36, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-01-16 17:25:25)
> >>
> >> On 16/01/2018 15:21, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-01-16 15:12:43)
> >>>>
> >>>> On 16/01/2018 13:05, Chris Wilson wrote:
> >>>>> +
> >>>>> + if (!new_requests_since_last_retire(dev_priv)) {
> >>>>> + __i915_gem_free_work(&dev_priv->mm.free_work);
> >>
> >> ... you wouldn't want to pull this up under the struct mutex section? It
> >> would need a different flavour of a function to be called, and some
> >> refactoring of the existing ones.
> >
> > "Some". I don't think that improves anything?
> >
> > The statement of intent to me is that we only throw away the caches and
> > excess memory if and only if we are idle. The presumption is that under
> > active conditions those caches are important, but if we are about to
> > sleep for long periods of time, we should be proactive in releasing
> > resources.
> >
> > I can hear you about to ask if we could add a timer and wake up in 10s to
> > prove we were idle!
>
> No, pointless since this proposal already runs outside this guarantee,
> and anyway, this was or the other there is potential to disrupt the next
> client.
>
> How about sticking in a break on new_request_since_last_retire() into
> __i915_gem_free_work()? Would that defeat the backlog cleaning? Maybe
> conditional only when called from the idle handler?
__i915_gem_free_work() is a distraction, since it is just clearing the
backlog of freed objects and shouldn't be affecting the cache
optimisations for the next/concurrent client. Let me try rearranging the
flow here.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
