Messages in this thread | | | Date | Mon, 16 Oct 2023 18:50:19 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 00/15] sched: EEVDF and latency-nice and/or slice-attr |
| |
Sorry, I seem to have forgotten to reply to this part...
On Mon, Oct 09, 2023 at 07:51:03PM -0500, Youssef Esmat wrote:
> I think looking at the sched latency numbers alone does not show the > complete picture. I ran the same input latency test again and tried to > capture some of these numbers for the chrome processes. > > EEVDF 1.5ms slice: > > Input latency test result: 226ms > perf sched latency: > switches: 1,084,694 > avg: 1.139 ms > max: 408.397 ms > > EEVDF 6.0ms slice: > > Input latency test result: 178ms > perf sched latency: > switches: 892,306 > avg: 1.145 ms > max: 354.344 ms
> For our scenario, it is very expensive to interrupt UI threads. It > will increase the input latency significantly. Lowering the scheduling > latency at the cost of switching out important threads can be very > detrimental in this workload. UI and input threads run with a nice > value of -8.
> That said, this might not be beneficial for all workloads, and we are > still trying our other workloads out.
Right, this seems to suggest something on your critical path (you should trace that) has more than 3ms of compute in a single activation.
Basically this means chrome is fairly fat on this critical path. But it seems you know about that.
Anyway, once you know the 95% length of the longest activation on your critical path, you can indeed set your slice to that. This should be readily available from trace data.
| |