On Mon, Mar 27, 2017 at 05:00:49PM +0300, Mika Kuoppala wrote: > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > On Mon, Mar 27, 2017 at 04:19:58PM +0300, Mika Kuoppala wrote: > >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > >> > >> > On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote: > >> >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > >> >> > >> >> > One POSTING_READ of ACTHD may not be enough to ensure that the seqno > >> >> > write has been posted from the GPU and is now visible. So do three! > >> >> > > >> >> > >> >> Is this about posting read triggering or just adding enough delay > >> >> that the write gets through? > >> > > >> > It's purely about a delay that we guess will cover 99.9999% of cases. > >> > >> Acked-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> > > > > Thanks, for checking over the idea. I'm going to apply it to > > topic/core-for-CI for some extended soak testing and see if that > > silences fi-snb-2600 > > Another thing that would be worth testing is to force a latency guarantee > through pm_qos. iirc removing a pm_qos was synchronous, so for shortlived/frequent requests they were a no-go (I tried holding pm_qos over the wait, which covers all the irq_seqno_barriers). It bumped our client latency metrics quite substantially. Ugh. Super ugly would be to take pm_qos whilst irq is enabled, just we keep that irq enabled all the time whilst the guc is active, artificially forcing the cpus to never sleep whilst the GPU is busy. On the other hand, they don't have seqno_barrier. Getting hacky. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
