Quoting Michał Winiarski (2017-11-24 12:37:56) > Since we see the effects for GuC preeption, let's gather some evidence. > > (SKL) > intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption' > > drm-tip: > usecs : count distribution > 0 -> 1 : 0 | | > 2 -> 3 : 0 | | > 4 -> 7 : 0 | | > 8 -> 15 : 44 | | > 16 -> 31 : 1088 | | > 32 -> 63 : 832 | | > 64 -> 127 : 0 | | > 128 -> 255 : 0 | | > 256 -> 511 : 12 | | > 512 -> 1023 : 0 | | > 1024 -> 2047 : 29899 |********* | > 2048 -> 4095 : 131033 |****************************************| Such pretty graphs. Reminds me of the bpf hist output, I wonder if we could create a tracepoint/kprobe that would output a histogram for each waiter (filterable ofc). Benefit? Just thinking of tuning the spin/sleep, in which case overall metrics are best (intel_eait_for_register needs to be optimised for the typical case). I am wondering if we could tune the spin period down to 5us, 2us? And then have the 10us sleep. We would also need a typical workload to run, it's profile-guided optimisation after all. Hmm. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
