At least on Windows, if I look at the affinity of everything else, then I don't see anything that's also insisting on being on core 0..7. So _in theory_ the work that's causing ~3% slowdown could migrate to other cores and shouldn't hurt perf. So I'm still not sure what happened there. As for the extra 15% slowdown when actually enabling the low priority pool... If that's really Linux saying "oh you wanted SCHED_BATCH threads, no problem" and they get 15% less CPU time, then... it's working great, I guess :) One option would be to semi-cheat and _disable_ the pool on Talos: if Talos tests are for detecting regressions in raw SVG rasterization speed, then the throughput-for-latency trade-off is irrelevant there. Another option is to put the "low priority" pool back to normal priority, and instead boost the "normal" pool to higher-than-normal. In theory, with nothing running on the higher priority pool, that should keep perf level at +- minus 3% from affinity. (Reminder that all of this is just a temporary workaround until we have a unified scheduler and/or yieldable SVG tasks.)
Bug 1604570 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
At least on Windows, if I look at the affinity of everything else, then I don't see anything that's also insisting on being on core 0..7. So _in theory_ the work that's causing ~3% slowdown could migrate to other cores and shouldn't hurt perf. So I'm still not sure what happened there. (Edit: >8 cores for Talos, and affinity prevents the pool from spreading out, causing -3% due to hyperthreading?) As for the extra 15% slowdown when actually enabling the low priority pool... If that's really Linux saying "oh you wanted SCHED_BATCH threads, no problem" and they get 15% less CPU time, then... it's working great, I guess :) One option would be to semi-cheat and _disable_ the pool on Talos: if Talos tests are for detecting regressions in raw SVG rasterization speed, then the throughput-for-latency trade-off is irrelevant there. Another option is to put the "low priority" pool back to normal priority, and instead boost the "normal" pool to higher-than-normal. In theory, with nothing running on the higher priority pool, that should keep perf level at +- minus 3% from affinity. (Reminder that all of this is just a temporary workaround until we have a unified scheduler and/or yieldable SVG tasks.)
At least on Windows, if I look at the affinity of everything else, then I don't see anything that's also insisting on being on core 0..7. So _in theory_ the work that's causing ~3% slowdown could migrate to other cores and shouldn't hurt perf. So I'm still not sure what happened there. (Edit: perhaps >8 cores for Talos, and affinity prevents the pool from spreading out, causing -3% due to hyperthreading?) As for the extra 15% slowdown when actually enabling the low priority pool... If that's really Linux saying "oh you wanted SCHED_BATCH threads, no problem" and they get 15% less CPU time, then... it's working great, I guess :) One option would be to semi-cheat and _disable_ the pool on Talos: if Talos tests are for detecting regressions in raw SVG rasterization speed, then the throughput-for-latency trade-off is irrelevant there. Another option is to put the "low priority" pool back to normal priority, and instead boost the "normal" pool to higher-than-normal. In theory, with nothing running on the higher priority pool, that should keep perf level at +- minus 3% from affinity. (Reminder that all of this is just a temporary workaround until we have a unified scheduler and/or yieldable SVG tasks.)