On Mon, Jul 04, 2016 at 09:51:15AM +0100, Patrick Bellasi wrote:
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...
Adding more noise and then add yet more features to try to counter it seems a bit counter-productive to me.
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
Or you keep moving around causing unnecessary task migrations.
The perturbation argument can be used for every single scheduling decision, good or bad :-)
If you really want to add perturbations to the task placement, I would suggest to make it explicit and much better controlled. It shouldn't be a random side effect somewhere. I'm not convinced myself about the idea. Perturbations are not free, and can easily cause more harm than good, so it has to be designed carefully.
I would suggest to aim for a stable scheduling policy by default, and then think about adding perturbations later if necessary.
Morten