7 ms·

> A NOTE ABOUT DEADLINES: While fair scheduling is appropriate for the vast majority of workloads, there are some tasks that require very specific timing and/or

> A NOTE ABOUT DEADLINES: While fair scheduling is appropriate for the vast majority of workloads, there are some tasks that require very specific timing and/or do not adapt well to overload conditions. For example, these workloads include low-latency audio / graphics, high-frequency sensors, and high-rate / low-latency networking. These specialized tasks are better served with a deadline scheduler, which is planned for later in the Zircon scheduler development cycle. Those seem like important workloads. Does this imply that the deadline scheduler runs concurrently with the fair scheduler? Otherwise, what's the point of developing an ideal scheduler for common workloads if it cannot be used for critical workloads. Is it common to run two different schedulers in the same system?

colechristensen 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      > (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 7y ago
  Three. And they're blended, which makes the selection hard. Latency, throughput, tolerance for dropped work.
coreytabaka 7y ago
It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.
- VanillaCafe 7y ago
  What does the super scheduler that coordinates the two schedulers approximately look like?
  - coreytabaka 7y ago
    A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution time, whereas fair work is elastic and can adjust to use the available bandwidth.
    - WhatIsDukkha 7y ago
      Where is io scheduling in this? It's my perception that on current workstations, for example, that and "ionice -c3" in front of any build I do is far more useful then simply nicing it.
      - coreytabaka 7y ago
        IO scheduling is a separate problem, though it shares the same fundamental properties. The same goes for network packet scheduling. All of these are ongoing efforts. Stay tuned! :)
        WhatIsDukkha 7y ago
        Well I look forward to seeing this develop. Two of my primary areas of interest, audio engineering and VR both REALLY show how poorly modern operating systems do with user interactivity when it counts.
  - the8472 7y ago
derefr 7y ago
Yes, it's common, though in many cases it's an implicit rather than explicit part of the design—"deadline scheduling" is just what happens when you allow kernel-mode drivers to register CPU interrupts (usually, these days, coming from DMA completion events.)

colechristensen 7y ago

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 7y ago
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 7y ago
  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 7y ago
    > (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 7y ago
Three. And they're blended, which makes the selection hard. Latency, throughput, tolerance for dropped work.

coreytabaka 7y ago

It does imply that. Multiple concurrent scheduling algorithms is nothing new, Linux and MacOS both support per-thread algorithm selection.

VanillaCafe 7y ago
What does the super scheduler that coordinates the two schedulers approximately look like?
- coreytabaka 7y ago
  A simple hierarchy: when there is deadline work to do that work takes precedence, fair work gets the rest of the time. This is effective because deadline work has bounded execution time, whereas fair work is elastic and can adjust to use the available bandwidth.
  - WhatIsDukkha 7y ago
    Where is io scheduling in this? It's my perception that on current workstations, for example, that and "ionice -c3" in front of any build I do is far more useful then simply nicing it.
    - coreytabaka 7y ago
      IO scheduling is a separate problem, though it shares the same fundamental properties. The same goes for network packet scheduling. All of these are ongoing efforts. Stay tuned! :)
      - WhatIsDukkha 7y ago
        Well I look forward to seeing this develop. Two of my primary areas of interest, audio engineering and VR both REALLY show how poorly modern operating systems do with user interactivity when it counts.
- the8472 7y ago

derefr 7y ago

Yes, it's common, though in many cases it's an implicit rather than explicit part of the design—"deadline scheduling" is just what happens when you allow kernel-mode drivers to register CPU interrupts (usually, these days, coming from DMA completion events.)