On Fri, May 13, 2016 at 10:19:11AM +0100, John Harrison wrote:
> On 13/05/2016 08:27, Chris Wilson wrote:
> >On Thu, May 12, 2016 at 10:06:34PM +0100, John.C.Harrison@xxxxxxxxx wrote:
> >>+void i915_gem_request_notify(struct intel_engine_cs *engine, bool fence_locked)
> >>+{
> >>+ struct drm_i915_gem_request *req, *req_next;
> >>+ unsigned long flags;
> >> u32 seqno;
> >>- seqno = req->engine->get_seqno(req->engine);
> >>+ if (list_empty(&engine->fence_signal_list))
> >>+ return;
> >>+
> >>+ if (!fence_locked)
> >>+ spin_lock_irqsave(&engine->fence_lock, flags);
> >>+
> >>+ if (engine->irq_seqno_barrier)
> >>+ engine->irq_seqno_barrier(engine);
> >>+ seqno = engine->get_seqno(engine);
> >>+
> >>+ list_for_each_entry_safe(req, req_next, &engine->fence_signal_list, signal_link) {
> >NO, NO, NO. As we said the very first time, you cannot do this from an
> >irq handler.
> >
> >The current code is already bad enough, this is making it large constant
> >+ N times worse. Please do look at how to do signal driven fences in O(1)
> >that I posted many months ago and several times since.
>
> If you have a better solution available then please post it in a
> form that can be merged and get it reviewed and accepted.
Recently reposted as
https://lists.freedesktop.org/archives/intel-gfx/2016-May/095040.html
It is currently blocking getting request + vma tracking overhauled to
fix our leaks, as well as the regression fixes that depend upon them.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
