Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Mika Kuoppala (2018-05-30 16:02:06) >> >> For the second issue where unlimited semaphore wait poll loop >> is generating the heavy memory traffic and preventing a reset, >> we add one microsecond poll interval to semaphore wait to >> guarantee bandwidth for the reset preration. The side effect >> is that we make semaphore completion latencies also 1us longer. > > You know the rule: second issue, second patch. That's odd, I would have > expected a MI_SEMA op to be an arbitration point (even inside the busy > wait loop), so would have expected it to behave nicely with STOP_RING.
My interpretation was that the context save gets delayed/stuck. -Mika _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
