On 14/03/14 14:12, Jon Medhurst (Tixy) wrote:
On Thu, 2014-03-13 at 17:47 +0000, Chris Redpath wrote:
When looking for a task to be idle-pulled, don't consider tasks where the affinity does not allow that task to be placed on the target CPU.
Signed-off-by: Chris Redpath chris.redpath@arm.com
kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d59e0de..df28dbf 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7178,7 +7178,8 @@ static unsigned int hmp_idle_pull(int this_cpu) * CPU is heavier than previous task */ if (hmp_task_eligible_for_up_migration(curr) &&
curr->avg.load_avg_ratio > ratio) {
curr->avg.load_avg_ratio > ratio &&cpumask_test_cpu(this_cpu, tsk_cpus_allowed(task_of(curr)))) { p = task_of(curr); target = rq; ratio = curr->avg.load_avg_ratio;If this change is needed, would not a similar change also be required in hmp_force_up_migration at the point where we changed it in the last patch to do the wake_for_idle_pull = 1 bit?
I don't believe we need it. When we are in hmp_force_up_migration the affinity is taken into account when deciding if a task can be up-migrated. This happens at
hmp_force_up_migration->hmp_up_migration->hmp_domain_min_load
when we return the target CPU. Note that hmp_domain_min_load returns the lowest loaded CPU in an hmp domain amongst the CPUs in the provided cpumask (if provided). force_up_migration provides the task affinity of the biggest task.
In the problem area we are just doing an idle pull inspection because a big CPU has gone idle. This doesn't use hmp_domain_min_load so we need to manage affinity separately.
There could be a potential problem in that if we have multiple large tasks on the same CPU to choose between and the running one was pinned, we would not be able to see the other one. However, hmp_get_heaviest_task already knows if the task selection is for an up-migration and will only return a task which has both enough load and is allowed to run on a bigger CPU. The risk is that we select a task which is able to move to a bigger CPU, but explicitly disallowed on the one we're going to move it to. I haven't seen such a situation, but nothing prevents it.
I can fix that by changing the second parameter for hmp_get_heaviest_task to take a CPU that the task must be allowed to move to. Both callers of this fn currently ask that the heaviest task is checked for affinity to at least some of the bigger domain, all I need to do is pass the CPU we are on from the idle pull caller.
--Chris