Quoting Rogozhkin, Dmitry V (2018-08-02 20:37:36) > I was actually surprised why they don't rely on i915 wait function. > They responded in was: "I would gladly always use bo_wait ioctl, but it > has big overhead for short workloads." Thus the question: do we have an > opportunity to improve? Can we have some dynamic way to configure > spinning for the particular requests/contexts? /if I understand > correctly current patch it introduces kernel config-level setting > rather than some dynamic setting/ Better yet, tell us about the problem with the overhead! The latency from batch to client (measuring RCS timestamp in batch to RCS timestamp in userspace) is 10us (bdw and the like), under controlled conditions ;) Hmm, that does drop a bit for a RT client which does also suggest that cpufreq is a factor there. A roundtrip through the wait ioctl doing nothing is 100ns; minimum wait due to irq setup is around 7us (spin then mmio before detecting completion immediately afterwards). If your measurements are orders of magnitude worse that too is enlightening. To justify a 10ms spin is that sleeping (hitting the scheduler) is unacceptable, which seems to be a widerscale problem. But that I recommend we look at https://patchwork.freedesktop.org/patch/241571/ to see if something like that helps us in the short term. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
