On Mon, Oct 12, 2015 at 11:07:21AM -0700, Steve Muckle wrote:
(adding eas-dev)
On 10/09/2015 01:41 AM, Patrick Bellasi wrote:
The users might not be happy though
so we could favor performance for RT tasks to avoid breaking legacy software and ask users that care about energy to migrate to deadline where we actually know the performance constraints of the tasks.
Given that at the moment RT tasks are treated no differently than CFS tasks w.r.t. cpu frequency I'd expect that we could get away without any sort of perf bias for RT bandwidth, which I think would be cost prohibitive for power.
Are you specifically considering instantaneous power? Because from a power standpoint I cannot see any difference for example w.r.t having a batch CFS task.
From an energy standpoint instead, do not you think that a "race-to-idle" policy could be better at least for RT-BATCH tasks?
Sorry I should have said energy rather than power...
From my experience race to idle has never panned out as an energy-efficient strategy, presumably due to the nonlinear increase in power cost as performance increases.
I agree with you that "race-to-idle" is not (always) a good energy-efficient strategy. However, is the _main_ goal of sched-DVFS to be energy-efficient?
In this case, what should we do for platforms where the lower OPP are less energy-efficient than some higher OPP? We just discovered from some discussions at Connect that there are many platforms adopting that strategy for certain different reasons.
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.
From this viewpoint, I think it's not so fare away from reality that,
if you schedule a task as FIFO or BATCH real-time, you care most about latencies, or you _should_ care about latencies. Specifically the time to completion of a task. If this is true the race-to-idle is the only "deterministic" way to achieve such a goal.
Because of this I think a policy of increasing the OPP when RT tasks are runnable will cause a net increase in energy consumption,
I would argue that this is hard to define in general. We actually do not know if running at a lower OPP could be more/less energy efficient. It depends from many other (possibly external) factors, e.g. OPP curves definition, interaction with I/O devices... Quite sure instead we will increase power consumption.
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.
which need not be incurred since RT tasks do not receive this preferential OPP treatment today.
Do they not receive such a preferred treatment just because CPUFreq as always been completely decoupled from scheduler specific information? If we use just the "average CPU idle time" to select the OPP once a while, that's according to me the reason why FIFO/BATCH don't get a specific treatment.
I think that on this specific point we should better get involved RT guys and ask them if a race-to-idle strategy could better match their expectations.
Maybe I'm wrong but I have the impression that once you schedule a task as FIFO/BATCH, sometimes you also need to "hack" into CPUFreq to ensure a minimum OPP which allows to match your tasks demands in terms of time-to-completion.
Here the problem is that with the frameworks we have right now people need to use/combine features of different frameworks to achieve their goals. This sounds to me like something which could be improved, provided that we start by splitting responsibility and let user know which tool should be used to achieve a specific goal.
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.
Cheers Patrick