On 05-Mar 20:44, Viresh Kumar wrote:
On 5 March 2018 at 18:22, Patrick Bellasi patrick.bellasi@arm.com wrote:
On 05-Mar 15:57, Viresh Kumar wrote:
Even if prefer_idle is disabled for such foreground tasks, they don't end up on the little CPUs. The reason being that find_best_target() still prefers big CPUs if the task is boosted, though some of the
^^^^^^^
Would say we don't prefer, but "just" start from big CPUs...
I wrote "prefer" here because that's where the current routine will take us to if at least one little and one big CPUs are idle, probably because of a bug.
comments in find_best_target() routine say the exact opposite of that.
I guess you are referring to this comment:
Yes.
This comment does not assume any visiting ordering... which is intentional since we wanna, potentially, go thought all the CPUs and find the best target by just doing min/max aggregations... more on that later.
Right, so its a bug that I am fixing now :)
It eventually depends on the order in which CPUs are processed, which is from big to little for boosted tasks.
Order matter yes, but in case B we still do a minimization of the capacity_orig... thus eventually preferring LITTLE over big IDLE CPUs.
Well, that's what we want to do but we will never do that. The very next statement after looking for lowest capacity is this:
if ((capacity_orig - min_capped_util) < target_idle_max_spare_cap) continue;
Hops, wait... got it... you are looking at the android-4.9-eas-dev branch!
... I was considering the "mainline" android-4.9 ACK
If we start from a big CPU, then the above expression will *always* evaluate to "true" for a little CPU and so we never go to the rest of the code for little CPUs. And that's a bug as we probably don't want that behavior.
Yes, looking at that code... it seems that we end up favouring a big CPU over a LITTLE... which is a behavior chance wrt the original code.
Let seem what we can do with the snippet above... since it's not yet merged in ACK...
The only exception to this is when "sysctl_sched_cstate_aware" is set... which could end up in selection a big CPU over a LITTLE just because it's in a shallowest IDLE state.
We don't reach here for little CPUs currently.
Being B the case of non latency sensitive tasks, I'm wondering how much sense still have that condition... since it's definitively affecting our min/max aggregation in a potential bad way...
Do you have this sysctl set in your use-cases?
Not sure. Is it enabled by default? I haven't changed anything related to that.
Without cstate awareness, I would say we always end up preferring a LITTLE over an big CPU... provided they are both IDLE. Isn't it?
We should, but we don't :)
-- viresh
-- #include <best/regards.h>
Patrick Bellasi