Quoting Tvrtko Ursulin (2019-02-28 13:20:50) > > On 26/02/2019 10:24, Chris Wilson wrote: > > If we resubmitting the active context, simply skip the submission as > > we are It took multiple reads to even notice that the third word was missing, mainly because I kept skipping the "we". > > performing the submission from the interrupt handler has higher > > From the tasklet? Yes, the interrupt handler bottom half. > You mean wait for ctx complete and then > execlists_dequeue, instead of lite-restore? Yes. We can measure the relatively large impact of lite-restoring on throughput (the delay in the GPU reloading the context is quite noticeable), but it only affects a certain microbenchmark. In theory, making sure we avoid the stall while handling the interrupt and resubmitting should offset that cost and be much preferred for multi-context situations, but there the interrupt overhead on an *idle* system (~5-7us) is not as significant and so the impact seems not as significant (in fact due to quirky hw, sometimes it is preferable not to resubmit during an inflight CS event). Anyway I just keep getting annoyed by the extra latency induced by lite-restore without a good way to balance it against avoiding the CS completion stall. And I live in fear of our tasklet being thrown to ksoftirqd again. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx