On 01-Jul 17:44, Morten Rasmussen wrote:
On Tue, Jun 28, 2016 at 11:46:14AM +0100, Patrick Bellasi wrote:
On 23-Jun 21:43, Leo Yan wrote:
Prefer to select idle CPU to place waken up task. So we can see the task can be more stable to spread to CPUs in the cluster and hope can decrease OPP for power saving.
It can potentially harm energy consumption a lot as you opt for more wake-ups instead of trying to use the spare cycles available on cpus already awake. However, if you are after latency improvements, this make a lot of sense.
@@ -5617,7 +5617,7 @@ static int energy_aware_wake_cpu(struct task_struct *p, int target)
if (new_util < capacity_curr_of(i)) { target_cpu = i;
if (cpu_rq(i)->nr_running)
if (!cpu_rq(i)->nr_running)Maybe we should link this change with a check on boosted value? It could make sense to use a spread strategy only for boosted tasks, where waking up a task on an idle CPU can have a positive effect on its time to completion.
As long as a non-boosted task with lower vruntime doesn't wake up just after and decides to pack on the same cpu preempting the boosted task ;-)
Well, this "a posteriori" analysis is valid for many EAS code paths... we cannot (yet) forecast the future. :-/
I'm not sure if it would lead to a stable task distribution if some tasks try to stick together while others try to escape.
That's a good point. If we go for a mixed packing-vs-spreading strategy there should be some metric/mechanism that allows to monitor and control oscillations...
However, since we know that EAS is looking for "local minimums", I would expect more likely scenarios in which: a) boosted tasks wakeup and spread, thus moving the system away from a potential local minimum b) non boosted tasks wakeup and pack, this moving the system toward a new (maybe even better) local minimum
-- #include <best/regards.h>
Patrick Bellasi