On 09-Mar 16:42, Leo Yan wrote:
On Mon, Mar 05, 2018 at 03:59:09PM +0000, Quentin Perret wrote:
On Monday 05 Mar 2018 at 20:36:18 (+0530), Viresh Kumar wrote:
On 5 March 2018 at 18:01, Quentin Perret quentin.perret@arm.com wrote:
So, if we want to start from little CPUs for boosted and non-prefer-idle tasks, what about just changing: cpu = start_cpu(boosted); by cpu = start_cpu(prefer_idle);
Well, in the prefer-idle case we really want to pick a big idle CPU instead of a little idle CPU (I am not very sure why) and so the order plays a role.
It's because the prefer-idle flag basically means "this task is latency sensitive". What we want is to wakeup the task ASAP (that's why we pick an idle CPU) and to complete it quickly (that's why we favor big CPUs, and why all prefer idle tasks are boosted).
In the non-prefer-idle case I think the code was designed to work irrespective of the order in which CPUs are parsed and just that we have a bug there which wouldn't let us select a little idle CPU. So, order shouldn't matter in that case and that's what this patch is trying to do.
A regular android system doesn't have such non-prefer-idle boosted tasks for now AFAIK, so the right thing to do isn't clear yet. Ionela is currently looking into those things, so I'd like to see her results before we decide what to do :) Maybe the simplest fix will be to simply start the iteration from the littlest CPU for all non-prefer-idle tasks, even if they're boosted. I think that should also fix the issue Leo noticed. Let's see :)
Just want to remind, for the boosting tasks, it's quite tricky to say should place it on big or LITTLE CPUs. The reason is, if we place one boosted task on a big CPU, and this big CPU has its saperate clock from LITTLE CPUs, then this boosted task doesn't interfere other tasks on LITTLE CPUs; on the other hand if we place this boosted task on LITTLE CPUs, this is easily to increase frequency on LITTLE CPUs and all other tasks on LITTLE CPUs also run at higher frequency and consume more power.
More power likely yes... but regarding energy it's kind of difficult to say. Wihtin certain ranges you could end up benefiting from a race-to-idle.
So if can find some specific boost margin, we can observe power regression after we place boosted task on LITTLE CPU.
I still want to sell my suggestion to use fbt() to choose candidates for every cluster (every cluster can have active and idle candidates), and compare energy for these candidates to select final target.
That's an interesting idea... did you already posted patches for it?
If so, fbt() doesn't consider different CPU variants and only focus on the same CPU variant. At the end all discussion for this patch will dismiss :D
At a certain level you should still plug in a heuristic to prefer the candidate target from one cluster or another... considering both the user-space hints (e.g. perfer_idle) as well as, potentially, a properly defined PESpace filtering... isn't it?
I mean, we cannot just blindly go for the most energy efficient target...
-- #include <best/regards.h>
Patrick Bellasi