linux-stable.git/kernel/sched/fair.c, branch v3.16

Merge branch 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-06-13T02:42:15+00:00

Pull more scheduler updates from Ingo Molnar:
 "Second round of scheduler changes:
   - try-to-wakeup and IPI reduction speedups, from Andy Lutomirski
   - continued power scheduling cleanups and refactorings, from Nicolas
     Pitre
   - misc fixes and enhancements"

* 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/deadline: Delete extraneous extern for to_ratio()
  sched/idle: Optimize try-to-wake-up IPI
  sched/idle: Simplify wake_up_idle_cpu()
  sched/idle: Clear polling before descheduling the idle thread
  sched, trace: Add a tracepoint for IPI-less remote wakeups
  cpuidle: Set polling in poll_idle
  sched: Remove redundant assignment to "rt_rq" in update_curr_rt(...)
  sched: Rename capacity related flags
  sched: Final power vs. capacity cleanups
  sched: Remove remaining dubious usage of "power"
  sched: Let 'struct sched_group_power' care about CPU capacity
  sched/fair: Disambiguate existing/remaining "capacity" usage
  sched/fair: Change "has_capacity" to "has_free_capacity"
  sched/fair: Remove "power" from 'struct numa_stats'
  sched: Fix signedness bug in yield_to()
  sched/fair: Use time_after() in record_wakee()
  sched/balancing: Reduce the rate of needless idle load balancing
  sched/fair: Fix unlocked reads of some cfs_b->quota/period

numa,sched: fix load_to_imbalanced logic inversion

2014-06-08T21:35:05+00:00

This function is supposed to return true if the new load imbalance is
worse than the old one.  It didn't.  I can only hope brown paper bags
are in style.

Now things converge much better on both the 4 node and 8 node systems.

I am not sure why this did not seem to impact specjbb performance on the
4 node system, which is the system I have full-time access to.

This bug was introduced recently, with commit e63da03639cc ("sched/numa:
Allow task switch if load imbalance improves")

Signed-off-by: Rik van Riel 
Signed-off-by: Linus Torvalds

Merge branch 'next' (accumulated 3.16 merge window patches) into master

2014-06-08T18:31:16+00:00

Now that 3.15 is released, this merges the 'next' branch into 'master',
bringing us to the normal situation where my 'master' branch is the
merge window.

* accumulated work in next: (6809 commits)
  ufs: sb mutex merge + mutex_destroy
  powerpc: update comments for generic idle conversion
  cris: update comments for generic idle conversion
  idle: remove cpu_idle() forward declarations
  nbd: zero from and len fields in NBD_CMD_DISCONNECT.
  mm: convert some level-less printks to pr_*
  MAINTAINERS: adi-buildroot-devel is moderated
  MAINTAINERS: add linux-api for review of API/ABI changes
  mm/kmemleak-test.c: use pr_fmt for logging
  fs/dlm/debug_fs.c: replace seq_printf by seq_puts
  fs/dlm/lockspace.c: convert simple_str to kstr
  fs/dlm/config.c: convert simple_str to kstr
  mm: mark remap_file_pages() syscall as deprecated
  mm: memcontrol: remove unnecessary memcg argument from soft limit functions
  mm: memcontrol: clean up memcg zoneinfo lookup
  mm/memblock.c: call kmemleak directly from memblock_(alloc|free)
  mm/mempool.c: update the kmemleak stack trace for mempool allocations
  lib/radix-tree.c: update the kmemleak stack trace for radix tree allocations
  mm: introduce kmemleak_update_trace()
  mm/kmemleak.c: use %u to print ->checksum
  ...

sched: Rename capacity related flags

2014-06-05T09:52:32+00:00

It is better not to think about compute capacity as being equivalent
to "CPU power".  The upcoming "power aware" scheduler work may create
confusion with the notion of energy consumption if "power" is used too
liberally.

Let's rename the following feature flags since they do relate to capacity:

	SD_SHARE_CPUPOWER  -> SD_SHARE_CPUCAPACITY
	ARCH_POWER         -> ARCH_CAPACITY
	NONTASK_POWER      -> NONTASK_CAPACITY

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Andy Fleming 
Cc: Anton Blanchard 
Cc: Benjamin Herrenschmidt 
Cc: Grant Likely 
Cc: Linus Torvalds 
Cc: Michael Ellerman 
Cc: Paul Gortmaker 
Cc: Paul Mackerras 
Cc: Preeti U Murthy 
Cc: Rob Herring 
Cc: Srivatsa S. Bhat 
Cc: Toshi Kani 
Cc: Vasant Hegde 
Cc: Vincent Guittot 
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/n/tip-e93lpnxb87owfievqatey6b5@git.kernel.org
Signed-off-by: Ingo Molnar

sched: Final power vs. capacity cleanups

2014-06-05T09:52:30+00:00

It is better not to think about compute capacity as being equivalent
to "CPU power".  The upcoming "power aware" scheduler work may create
confusion with the notion of energy consumption if "power" is used too
liberally.

This contains the architecture visible changes.  Incidentally, only ARM
takes advantage of the available pow^H^H^Hcapacity scaling hooks and
therefore those changes outside kernel/sched/ are confined to one ARM
specific file.  The default arch_scale_smt_power() hook is not overridden
by anyone.

Replacements are as follows:

	arch_scale_freq_power  --> arch_scale_freq_capacity
	arch_scale_smt_power   --> arch_scale_smt_capacity
	SCHED_POWER_SCALE      --> SCHED_CAPACITY_SCALE
	SCHED_POWER_SHIFT      --> SCHED_CAPACITY_SHIFT

The local usage of "power" in arch/arm/kernel/topology.c is also changed
to "capacity" as appropriate.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Arnd Bergmann 
Cc: Dietmar Eggemann 
Cc: Grant Likely 
Cc: Linus Torvalds 
Cc: Mark Brown 
Cc: Rob Herring 
Cc: Russell King 
Cc: Sudeep KarkadaNagesha 
Cc: Vincent Guittot 
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-48zba9qbznvglwelgq2cfygh@git.kernel.org
Signed-off-by: Ingo Molnar

sched: Remove remaining dubious usage of "power"

2014-06-05T09:52:29+00:00

It is better not to think about compute capacity as being equivalent
to "CPU power".  The upcoming "power aware" scheduler work may create
confusion with the notion of energy consumption if "power" is used too
liberally.

This is the remaining "power" -> "capacity" rename for local symbols.
Those symbols visible to the rest of the kernel are not included yet.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Linus Torvalds 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-yyyhohzhkwnaotr3lx8zd5aa@git.kernel.org
Signed-off-by: Ingo Molnar

sched: Let 'struct sched_group_power' care about CPU capacity

2014-06-05T09:52:26+00:00

It is better not to think about compute capacity as being equivalent
to "CPU power".  The upcoming "power aware" scheduler work may create
confusion with the notion of energy consumption if "power" is used too
liberally.

Since struct sched_group_power is really about compute capacity of sched
groups, let's rename it to struct sched_group_capacity. Similarly sgp
becomes sgc. Related variables and functions dealing with groups are also
adjusted accordingly.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Linus Torvalds 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-5yeix833vvgf2uyj5o36hpu9@git.kernel.org
Signed-off-by: Ingo Molnar

sched/fair: Disambiguate existing/remaining "capacity" usage

2014-06-05T09:52:25+00:00

We have "power" (which should actually become "capacity") and "capacity"
which is a scaled down "capacity factor" in terms of unitary tasks.
Let's use "capacity_factor" to make room for proper usage of "capacity"
later.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Linus Torvalds 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-gk1co8sqdev3763opqm6ovml@git.kernel.org
Signed-off-by: Ingo Molnar

sched/fair: Change "has_capacity" to "has_free_capacity"

2014-06-05T09:52:22+00:00

The capacity of a CPU/group should be some intrinsic value that doesn't
change with task placement.  It is like a container which capacity is
stable regardless of the amount of liquid in it (its "utilization")...
unless the container itself is crushed that is, but that's another story.

Therefore let's rename "has_capacity" to "has_free_capacity" in order to
better convey the wanted meaning.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Linus Torvalds 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-djzkk027jm0e8x8jxy70opzh@git.kernel.org
Signed-off-by: Ingo Molnar

sched/fair: Remove "power" from 'struct numa_stats'

2014-06-05T09:52:14+00:00

It is better not to think about compute capacity as being equivalent
to "CPU power".  The upcoming "power aware" scheduler work may create
confusion with the notion of energy consumption if "power" is used too
liberally.

To make things explicit and not create more confusion with the existing
"capacity" member, let's rename things as follows:

	power    -> compute_capacity
	capacity -> task_capacity

Note: none of those fields are actually used outside update_numa_stats().

Signed-off-by: Nicolas Pitre 
Signed-off-by: Peter Zijlstra 
Cc: Vincent Guittot 
Cc: Daniel Lezcano 
Cc: Morten Rasmussen 
Cc: "Rafael J. Wysocki" 
Cc: linaro-kernel@lists.linaro.org
Cc: Linus Torvalds 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-2e2ndymj5gyshyjq8am79f20@git.kernel.org
Signed-off-by: Ingo Molnar