sched/fair: fix a problem with boost placement

commit 1d19c97f ("sched/fair:
improve placement logic") introduced a problem where a boosted
task would end up on smaller capacity cpu when it could have
been placed on a higher capacity cpu.

When a task needs to be placed we traverse the clusters in increasing
order of capacities and when a suitable cpu is found, as indicated
by target_capacity != ULONG_MAX we exit the traversal.

For a boosted task, the code starts with mid capacity cluster and
even if a suitable cpu is found, we look for a better cpu in the
higher capacity cluster. That traversal to higher capacity cluster
is achieved by setting target_capacity to ULONG_MAX.
We skip setting it to ULONG_MAX when it is already at the highest
capacity cluster, this is so that we do not end up visiting smaller
capacity clusters.

The above logic to avoid visiting smaller cluster has a bug in it,
where if the highest cap cluster could not accommodate the task,
target_capacity continues to remain ULONG_MAX, causing us to visit
smaller capacity clusters. Visiting smaller capacity could end up
picking up an idle cpu or an active cpu from the smaller cluster,
and the energy evaluation or the packing eligibility checks endup
favoring the smaller capacity cpu.

To fix this, once we are at the higher capacity cluster, check if
we've found an active or idle cpu, and if so do not visit the smaller
clusters. If we haven't found a cpu, then it is appropriate to visit
smaller clusters.

There is another caveat, if all the cpus in highest capacity cluster
were offlined, since is_max_capacity_cpu() still regards them as highest
capacity, we would end up setting the target_capacity to ULONG_MAX
while we are at last but one cluster. But since there is no highest
capacity cluster, we would end up with target_capacity set to ULONG_MAX
and would visit smaller cluster. To fix this, we need ensure that the
cpus in the next group are indeed higher capacity before we set the
target_capacity to ULONG_MAX. If they arent higher, that indicates
we've reached the highest capacity cluster.

Change-Id: I9b4a8fd685ad68282bbd907bdd3160425984b2f6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>