On 09/03/2018 09: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. So if can find some specific boost margin, we can observe power regression after we place boosted task on LITTLE CPU.
Hi Leo,
I'm missing the point about a separate clock line for bL. If the task is placed on a big CPUs, the other big CPUs will also be impacted and we will see a frequency increase on the big cluster and the same power regression, no ?
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.
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
Thanks, Leo Yan
-- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog