linux.git/kernel/sched/fair.c, branch v4.7-rc2

sched/fair: Correct unit of load_above_capacity

2016-05-12T07:55:33+00:00

In calculate_imbalance() load_above_capacity currently has the unit
[capacity] while it is used as being [load/capacity]. Not only is it
wrong it also makes it unlikely that load_above_capacity is ever used
as the subsequent code picks the smaller of load_above_capacity and
the avg_load

This patch ensures that load_above_capacity has the right unit
[load/capacity].

Signed-off-by: Morten Rasmussen 
[ Changed changelog to note it was in capacity unit; +rebase. ]
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Dietmar Eggemann 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1461958364-675-4-git-send-email-dietmar.eggemann@arm.com
Signed-off-by: Ingo Molnar

sched/fair: Clean up scale confusion

2016-05-12T07:55:33+00:00

Wanpeng noted that the scale_load_down() in calculate_imbalance() was
weird. I agree, it should be SCHED_CAPACITY_SCALE, since we're going
to compare against busiest->group_capacity, which is in [capacity]
units.

Reported-by: Wanpeng Li 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Morten Rasmussen 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Yuyang Du 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

sched/fair: Fix fairness issue on migration

2016-05-12T07:55:32+00:00

Pavan reported that in the presence of very light tasks (or cgroups)
the placement of migrated tasks can cause severe fairness issues.

The problem is that enqueue_entity() places the task before it updates
time, thereby it can place the task far in the past (remember that
light tasks will shoot virtual time forward at a high speed, so in
relation to the pre-existing light task, we can land far in the past).

This is done because update_curr() needs the current task, and we
might be placing the current task.

The obvious solution is to differentiate between the current and any
other task; placing the current before we update time, and placing any
other task after, such that !curr tasks end up at the current moment
in time, and not in the past.

This commit re-introduces the previously reverted commit:

  3a47d5124a95 ("sched/fair: Fix fairness issue on migration")

... which is now safe to do, after we've also fixed another
underlying bug first, in:

  sched/fair: Prepare to fix fairness problems on migration

and cleaned up other details in the migration code:

  sched/core: Kill sched_class::task_waking

Reported-by: Pavan Kondeti 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

sched/core: Kill sched_class::task_waking to clean up the migration logic

2016-05-12T07:55:31+00:00

With sched_class::task_waking being called only when we do
set_task_cpu(), we can make sched_class::migrate_task_rq() do the work
and eliminate sched_class::task_waking entirely.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Hunter 
Cc: Ben Segall 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Mike Galbraith 
Cc: Mike Galbraith 
Cc: Morten Rasmussen 
Cc: Paul Turner 
Cc: Pavan Kondeti 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: byungchul.park@lge.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

sched/fair: Prepare to fix fairness problems on migration

2016-05-12T07:55:31+00:00

Mike reported that our recent attempt to fix migration problems:

  3a47d5124a95 ("sched/fair: Fix fairness issue on migration")

broke interactivity and the signal starve test. We reverted that
commit and now let's try it again more carefully, with some other
underlying problems fixed first.

One problem is that I assumed ENQUEUE_WAKING was only set when we do a
cross-cpu wakeup (migration), which isn't true. This means we now
destroy the vruntime history of tasks and wakeup-preemption suffers.

Cure this by making my assumption true, only call
sched_class::task_waking() when we do a cross-cpu wakeup. This avoids
the indirect call in the case we do a local wakeup.

Reported-by: Mike Galbraith 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Hunter 
Cc: Ben Segall 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Mike Galbraith 
Cc: Morten Rasmussen 
Cc: Paul Turner 
Cc: Pavan Kondeti 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: byungchul.park@lge.com
Cc: linux-kernel@vger.kernel.org
Fixes: 3a47d5124a95 ("sched/fair: Fix fairness issue on migration")
Signed-off-by: Ingo Molnar

sched/fair: Move record_wakee()

2016-05-12T07:55:30+00:00

Since I want to make ->task_woken() conditional on the task getting
migrated, we cannot use it to call record_wakee().

Move it to select_task_rq_fair(), which gets called in almost all the
same conditions. The only exception is if the woken task (@p) is
CPU-bound (as per the nr_cpus_allowed test in select_task_rq()).

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Hunter 
Cc: Ben Segall 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Mike Galbraith 
Cc: Mike Galbraith 
Cc: Morten Rasmussen 
Cc: Paul Turner 
Cc: Pavan Kondeti 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: byungchul.park@lge.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

Merge branch 'smp/hotplug' into sched/core, to resolve conflicts

2016-05-12T07:51:36+00:00

Conflicts:
	kernel/sched/core.c

Signed-off-by: Ingo Molnar

Merge branch 'sched/urgent' into sched/core to pick up fixes

2016-05-12T07:18:13+00:00

Signed-off-by: Ingo Molnar

Revert "sched/fair: Fix fairness issue on migration"

2016-05-11T06:25:53+00:00

Mike reported that this recent commit:

  3a47d5124a95 ("sched/fair: Fix fairness issue on migration")

... broke interactivity and the signal starvation test.

We have a proper fix series in the works but ran out of time for
v4.6, so revert the commit.

Reported-by: Mike Galbraith 
Acked-by: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

sched/fair: Fix !CONFIG_SMP kernel cpufreq governor breakage

2016-05-07T05:45:34+00:00

The following commit:

  34e2c555f3e1 ("cpufreq: Add mechanism for registering utilization update callbacks")

overlooked the fact that update_load_avg(), where CFS invokes cpufreq
utilization update callbacks, becomes an empty stub on UP kernels.

In consequence, if !CONFIG_SMP, cpufreq governors are never invoked
from CFS and they do not have a chance to evaluate CPU performace
levels and update them often enough.

Needless to say, things don't work as expected then.

Fix the problem by making the !CONFIG_SMP stub of update_load_avg()
invoke cpufreq update callbacks too.

Reported-by: Steve Muckle 
Tested-by: Steve Muckle 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Steve Muckle 
Cc: Linus Torvalds 
Cc: Linux PM list 
Cc: Peter Zijlstra 
Cc: Srinivas Pandruvada 
Cc: Thomas Gleixner 
Cc: Viresh Kumar 
Fixes: 34e2c555f3e1 (cpufreq: Add mechanism for registering utilization update callbacks)
Link: http://lkml.kernel.org/r/6282396.VVEdgVYxO3@vostro.rjw.lan
Signed-off-by: Ingo Molnar