Have you looked at how network QoS does it?

The CBQ and HTB are queuing disciplines attempting to solve the problem of having a single link between protocols needing guaranteed low latency but low traffic (eg, VoIP and interactive like ssh), tasks that need to a responsive link with uneven loads (eg, http), and that just need heaps of "low grade" bandwidth (eg, email). They use ad hoc techniques like the ones described here, and mostly work on a good day - but sometimes don't. And they are computationally expensive.

HFSC came later and solves the same problem. It has a rigorous mathematical analysis behind it, delivers perfect results, and is computationally inexpensive. The key turns out to be how you pose the problem. Doing that in a way that allows you to come up with a robust solution is non-obvious, or at least I found it non-obvious. Interesting, like the proposed solution here HFSC must also take into account what bandwidth was used and went unused in the past to determine what can be used the future.

Unfortunately CPU scheduling and QoS are only similar, not identical. QoS has the luxury of the application breaking the work it presents to the QoS scheduled into bite sized pieces - packets. The QoS problem reduces to deciding which of these packets to send next, and when. In CPU scheduling you have a number of tasks lining up to use the CPU that will run for an unknown amount of time. The problem reduces to "how long can I let this task run, before I interrupt it". Nonetheless, I suspect they have one thing in common: in order to do their jobs well, the mathematical model behind them must be perfect.