+Saravana (QC DVFS)
Caveat, I haven't read through the whole thread but wanted to comment on a few points:
However, is the _main_ goal of sched-DVFS to be energy-efficient?
I'm not sure it's the _main_ goal, but DVFS behavior does contribute heavily towards overall system energy-efficiency and performance, so it should be an important goal.
IMHO one of the "main" goal of sched-DVFS is to contribute to provide (as much as possible) deterministic behaviors. We have the chance to refactor CPUFreq to better integrate with the scheduler and thus we should try to exploit this opportunity to improve the overall determines of the solution.
Deterministic behavior would be great. However, we should also be mindful of response latency, so I would describe it as deterministic with minimal latency. I'm also concerned about trying to closely match dvfs response to scheduler demand. This is a policy decision and not always what you want.
But again, the goal of sched-DVFS is to be energy-efficient? I think that this responsibility should be better assigned to other players, i.e. scheduling classes.
I think scheduling classes can play a part in managing scheduler demand but don't think they are sufficient as the only DVFS management policy.
Specifically, if you care about responsiveness and energy-efficiency, you should better use DEADLINE instead of FIFO/RR. While if you go for this last class, than you should be aware that you get a race-to-idle behavior, whatever this means from an energy/power standpoint.
I'm hoping you mean that DEADLINE is preferred over FIFO/RR as a better way for EAS to manage energy-efficiency. That makes sense to me for RT, but there still needs to be a plan for EAS to handle FIFO/RR in a sane manner.
- Bryan