[PATCH 9/9] cpu/idle.c: move to sched/idle.c

2014-01-26 Thread Nicolas Pitre
Integration of cpuidle with the scheduler requires that the idle loop be closely integrated with the scheduler proper. Moving cpu/idle.c into the sched directory will allow for a smoother integration, and eliminate a subdirectory which contained only one source file. Signed-off-by: Nicolas Pitre

[PATCH 8/9] X86: remove redundant cpuidle_idle_call()

2014-01-26 Thread Nicolas Pitre
The core idle loop now takes care of it. Signed-off-by: Nicolas Pitre --- arch/x86/kernel/process.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 3fb8d95ab8..4505e2a950 100644 --- a/arch/x86/kernel/process.c ++

[PATCH 6/9] PPC: remove redundant cpuidle_idle_call()

2014-01-26 Thread Nicolas Pitre
The core idle loop now takes care of it. However a few things need checking: - Invocation of cpuidle_idle_call() in pseries_lpar_idle() happened through arch_cpu_idle() and was therefore always preceded by a call to ppc64_runlatch_off(). To preserve this property now that cpuidle_idle_call

[PATCH 7/9] SH: remove redundant cpuidle_idle_call()

2014-01-26 Thread Nicolas Pitre
The core idle loop now takes care of it. Signed-off-by: Nicolas Pitre --- arch/sh/kernel/idle.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c index 2ea4483fd7..be616ee0cf 100644 --- a/arch/sh/kernel/idle.c +++ b/arch/sh/kerne

[PATCH 5/9] ARM: remove redundant cpuidle_idle_call()

2014-01-26 Thread Nicolas Pitre
The core idle loop now takes care of it. Signed-off-by: Nicolas Pitre --- arch/arm/kernel/process.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index 725b8c95e0..34a59b7614 100644 --- a/arch/arm/kerne

[PATCH 4/9] idle: move the cpuidle entry point to the generic idle loop

2014-01-26 Thread Nicolas Pitre
In order to integrate cpuidle with the scheduler, we must have a better proximity in the core code with what cpuidle is doing and not delegate such interaction to arch code. Architectures implementing arch_cpu_idle() should simply enter a cheap idle mode in the absence of a proper cpuidle driver.

[PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()

2014-01-26 Thread Nicolas Pitre
ARM and ARM64 are the only two architectures implementing arch_cpu_idle_prepare() simply to call local_fiq_enable(). We have secondary_start_kernel() already calling local_fiq_enable() and this is done a second time in arch_cpu_idle_prepare() in that case. And enabling FIQs has nothing to do with

[PATCH 3/9] idle: no more arch_cpu_idle_prepare() users

2014-01-26 Thread Nicolas Pitre
... so we can get rid of it entirely. Signed-off-by: Nicolas Pitre --- include/linux/cpu.h | 1 - kernel/cpu/idle.c | 2 -- 2 files changed, 3 deletions(-) diff --git a/include/linux/cpu.h b/include/linux/cpu.h index 03e235ad1b..218fab7521 100644 --- a/include/linux/cpu.h +++ b/include/linux/

[PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()

2014-01-26 Thread Nicolas Pitre
ARM and ARM64 are the only two architectures implementing arch_cpu_idle_prepare() simply to call local_fiq_enable(). We have secondary_start_kernel() already calling local_fiq_enable() and this is done a second time in arch_cpu_idle_prepare() in that case. And enabling FIQs has nothing to do with

[PATCH 0/9] setting the table for integration of cpuidle with the scheduler

2014-01-26 Thread Nicolas Pitre
As everyone should know by now, we want to integrate the cpuidle governor with the scheduler for a more efficient idling of CPUs. In order to help the transition, this small patch series moves the existing interaction with cpuidle from architecture code to generic core code. No functional change s

Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory

2014-01-26 Thread Joonsoo Kim
On Fri, Jan 24, 2014 at 05:10:42PM -0800, Nishanth Aravamudan wrote: > On 24.01.2014 [16:25:58 -0800], David Rientjes wrote: > > On Fri, 24 Jan 2014, Nishanth Aravamudan wrote: > > > > > Thank you for clarifying and providing a test patch. I ran with this on > > > the system showing the original