[colechristensen]

Different scheduling algorithms and implementations have tradeoffs. Pick one based on your workload. No need to have only one for all applications.

You can approximate the choice down to two dimensions, latency vs. throughput. Pick your poison.

[VanillaCafe]

For instance, I assume for instance a common workload that would otherwise benefit from the fair scheduler has a fair chance of wanting to do low latency audio. I believe Android has had this issue. As soon as the platform cares about low latency audio it would need to abandon the fair scheduler?

[colechristensen]

Low latency audio would fit for doing live or studio audio production, not necessarily watching videos, listening to music or doing video calls (where there is already network delay an order of magnitude larger than the scheduler would impart). "Low" will have context-dependent meaning.

If you're doing low latency audio or flight controls on an aircraft for example, you would absolutely need to abandon the fair scheduler for one that could guarantee the deadlines you need are met. Sacrificing "performance" that is throughput/efficiency/etc of your processor for timing performance.

Think of the difference between doing statistics on a billion lines of data and flight controls on a missile. VERY different needs for scheduling, why not have a selectable algorithm?

[jblow]

> (where there is already network delay an order of magnitude larger than the scheduler would impart)

Not the right way to think about it; the connection latency is irrelevant. What is relevant is that you need to play audio in sync with the video, and that audio is coming to you approximately simultaneously with the video it's meant to be synced with.

[cbetti]

Three. And they're blended, which makes the selection hard. Latency, throughput, tolerance for dropped work.