Ah, sorry; I missed this point.If yes, I think your approach is safe (and easier to implement - modulo a
small
issue when a task terminates of switches to other scheduling policies; I
think
there already are some "XXX" comments in the current code). However, it
allows to
save less energy (or reclaim less CPU time). For example, if I create a
SCHED_DEADLINE
task with runtime 90ms and period 100ms it will not allow to scale the CPU
frequency
even if it never executes (because is always blocked).
Yes, i agree. If the task behavior is not aligned with its deadline
parameters, we will over provisioned CPU capacity to the deadline
scheduler.
This metric is not used to select the OPP but to provisioned some CPU
capacity to the deadline scheduler and to inform the CFS scheduler of
the remaining capacity.
Well, this is just nitpicking, so feel free to ignore (I just mentioned+ /* This is the "average utilization" for this runqueue */
+ s64 avg_bw;
};
Small nit: why "average" utilization? I think a better name would be
"runqueue utilization"
or "local utilization", or something similar... If I understand correctly
(sorry if I
missed something), this is not an average, but the sum of the utilisations
of the tasks
on this runqueue... No?
I have used "average" because it doesn't reflect the active/actual
utilization of the run-queue but the forecasted average bandwidth of
the CPU that will be used by deadline task.
I'm open to change the name if another one makes more senseIn real-time literature this is often called simply "utilization" (or "worst-case