3 ms·
It's not so much that the kernel devs are actively making "latency tradeoffs" -- it's that they absolutely can't get away with regressions It would be complete
by blasdel 17y ago
It's not so much that the kernel devs are actively making "latency tradeoffs" -- it's that they absolutely can't get away with regressions
It would be completely untenable if the corporate users (who are in the vast majority by every metric) ended up either not upgrading or using a fork that reverts the changes.
- three14 17y agoBut any change to the scheduler is a regression for someone, more or less by definition. Do you mean that they can't change it anymore at all?
- nitrogen 17y agoI suppose I see using a "one size fits all" scheduler as inherently full of tradeoffs between desktop, realtime, server, and 4096-core-compute-system requirements. IMO distributions and kernel hackers should be able to choose a scheduler that is optimal for their target audience. RHEL would probably stick with CFS, but Ubuntu Studio could use something more latency-oriented, like BFS. Maybe if CK keeps bringing up the issue, eventually someone will figure out an optimal way of measuring perceived latency that will prove or disprove the anecdotes given by CK's "followers."