Frankly, I solved this by trial and error. The hard real-time tasks need 15 of the first 20 cycles; the structure of the SFQ algorithm causes one cycle of round-robin scheduling before the weights come into effect. I set the weight of the batch processes to 1/100 so they wouldn't interfere, set the weight of the hard real-time processes to 1, and experimented with the weight on the multimedia processes. Setting their weight to 4 gave the following top-level schedule:
(the multimedia starts getting a lot of extra time at time 20 because the realtime tasks are all done).
The hard realtime tasks are scheduled using SSTF. This ends up looking like the following:
It turns out that the multimedia gets little enough time that its "best-effort" constraint completely dominates whatever scheduling algorithm is selected. It isn't possible for M2 to get enough time to meet its deadline on either of its first two cycles, while M1 needs to get every cycle allocated to the class to make its deadlines. The result is that the multimedia class scheduling looks like this:
Last and definitely least, we have the batch processes. By the time we've doled out cycles to the higher weighted classes, we've only got two cycles (2 and 25) to give to the batch jobs. So they look like this:
So, here's a figure putting it all together: it combines the Gantt charts from the previous figures, but doesn't show the virtual time.
