On 05/03/18 15:14, 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;
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, this condition was introduced by me with the minimum capacity capping patches to insure that we don't choose a CPU that is forced to run at an unusual high OPP by external actors. But I agree it does cause issues here, for cases in which the min cap is 0, and the bigs will (almost) always offer bigger spare. Probably a better decision is to consider the minimum cap on its own, and skip CPUs where this is high (still pondering if this should be relative to new util or not).
Ionela.
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 _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev