Adding periods to SCHED_DEADLINE

When looking at the example, I believe both the current bandwidth and the future bandwidth need to be checked separately. I can envision the scheduler having 100% usage from now into the future and yet have a very low future bandwidth.

For example a current SCHED_DEADLINE process has claimed 100% until its deadline in 10ms but won't reschedule for 1000ms afterwards.

I can also see having 100% free for a while and 100% used later.
E.g. the current process has completed and won't reschedule for 1000ms but the total reserved is 100% of the CPU then...

Looking at it, it seems it does not matter if the period and deadline are separate or not, the current schedule must be tested against the first deadline regardless of when that will be and the periodic bandwidth must be tested separately against future bandwidth reservations.

The simplest method that comes to mind for the current schedule is to just walk the schedule forward and see when enough free ms have accumulated before the proposed deadline is hit...
I am fairly sure most heuristics will have bad to very bad corner cases either not offering cpu time when available or oversubscribing.