[tip:timers/urgent] timers: Fix excessive granularity of new timers after a nohz idle

Commit-ID: 2fe59f507a65dbd734b990a11ebc7488f6f87a24 Gitweb: http://git.kernel.org/tip/2fe59f507a65dbd734b990a11ebc7488f6f87a24 Author: Nicholas Piggin <npig...@gmail.com> AuthorDate: Tue, 22 Aug 2017 18:43:48 +1000 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:timers/urgent] timers: Fix excessive granularity of new timers after a nohz idle

Commit-ID: 2fe59f507a65dbd734b990a11ebc7488f6f87a24 Gitweb: http://git.kernel.org/tip/2fe59f507a65dbd734b990a11ebc7488f6f87a24 Author: Nicholas Piggin AuthorDate: Tue, 22 Aug 2017 18:43:48 +1000 Committer: Thomas Gleixner CommitDate: Thu, 24 Aug 2017 11:40:18 +0200 timers: Fix

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Tue, 22 Aug 2017 11:19:02 +0200 Michal Simek <mon...@monstr.eu> wrote: > On 20.8.2017 05:36, Nicholas Piggin wrote: > > On Sun, 20 Aug 2017 08:37:36 +0800 > > kbuild test robot <fengguang...@intel.com> wrote: > > > >> Hi Nicholas, >

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Tue, 22 Aug 2017 11:19:02 +0200 Michal Simek wrote: > On 20.8.2017 05:36, Nicholas Piggin wrote: > > On Sun, 20 Aug 2017 08:37:36 +0800 > > kbuild test robot wrote: > > > >> Hi Nicholas, > >> > >> FYI, the error/warning still remains. >

[PATCH v2] timers: Fix excessive granularity of new timers after a nohz idle

Tested-by: Jonathan Cameron <jonathan.came...@huawei.com> Tested-by: David Miller <da...@davemloft.net> Signed-off-by: Nicholas Piggin <npig...@gmail.com> --- - Address Thomas' comments (hopefully). - Reword the changelog a bit. - Added Jonathan's tested-by kernel

[PATCH v2] timers: Fix excessive granularity of new timers after a nohz idle

Tested-by: Jonathan Cameron Tested-by: David Miller Signed-off-by: Nicholas Piggin --- - Address Thomas' comments (hopefully). - Reword the changelog a bit. - Added Jonathan's tested-by kernel/time/timer.c | 50 +- 1 file changed, 41 insertions

Re: [PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle

On Tue, 22 Aug 2017 09:45:46 +0200 (CEST) Thomas Gleixner <t...@linutronix.de> wrote: > On Tue, 22 Aug 2017, Nicholas Piggin wrote: > > I would have preferred to get comments from the timer maintainers, but > > they've been busy or away for the past copule of weeks. Perhaps y

Re: [PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle

On Tue, 22 Aug 2017 09:45:46 +0200 (CEST) Thomas Gleixner wrote: > On Tue, 22 Aug 2017, Nicholas Piggin wrote: > > I would have preferred to get comments from the timer maintainers, but > > they've been busy or away for the past copule of weeks. Perhaps you > > would consi

[PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle

ale: max avg std upstream 9.01.05 0.19 patched 2.01.04 0.11 Tested-by: David Miller <da...@davemloft.net> Signed-off-by: Nicholas Piggin <npig...@gmail.com> --- Hi Andrew, I would have preferred to get comments from the timer maintainers, b

[PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle

ale: max avg std upstream 9.01.05 0.19 patched 2.01.04 0.11 Tested-by: David Miller Signed-off-by: Nicholas Piggin --- Hi Andrew, I would have preferred to get comments from the timer maintainers, but they've been busy or away for the past cop

[no subject]

dle for longer than 4 seconds, which limits the granularity errors. Sub-optimal timer behaviour is observable on a smaller scale: max avg std upstream 9.01.05 0.19 patched 2.01.04 0.11 Tested-by: David Miller <da...@davemloft.net> Signed-off-by:

[no subject]

dle for longer than 4 seconds, which limits the granularity errors. Sub-optimal timer behaviour is observable on a smaller scale: max avg std upstream 9.01.05 0.19 patched 2.01.04 0.11 Tested-by: David Miller Signed-off-by: Nicholas Piggin --- Hi Andrew,

[PATCH 2/2] sched/idle: Use spin loop primitives for polling idle

Signed-off-by: Nicholas Piggin <npig...@gmail.com> --- kernel/sched/idle.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index 6c23e30c0e5c..b884980da8ef 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -11,6

[PATCH 2/2] sched/idle: Use spin loop primitives for polling idle

Signed-off-by: Nicholas Piggin --- kernel/sched/idle.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index 6c23e30c0e5c..b884980da8ef 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -11,6 +11,7 @@ #include

[PATCH 1/2] locking: Use spin primitives for busy loops

Commit fd851a3cdc ("spin loop primitives for busy waiting") introduced a begin/relax/end sequence for busy loops, to improve behaviour with some architectures. Convert most of the generic locking primitives over to use these spin primitives. Signed-off-by: Nicholas Piggin <npig

[PATCH 1/2] locking: Use spin primitives for busy loops

Commit fd851a3cdc ("spin loop primitives for busy waiting") introduced a begin/relax/end sequence for busy loops, to improve behaviour with some architectures. Convert most of the generic locking primitives over to use these spin primitives. Signed-off-by: Nicholas Piggin --- inc

[PATCH 0/2] start using spin primitives in sched and locking

Nicholas Piggin (2): locking: Use spin primitives for busy loops sched/idle: Use spin loop primitives for polling idle include/linux/bit_spinlock.h| 5 ++--- include/linux/seqlock.h | 9 - kernel/locking/mcs_spinlock.h | 6 ++ kernel/locking/mutex.c

[PATCH 0/2] start using spin primitives in sched and locking

Nicholas Piggin (2): locking: Use spin primitives for busy loops sched/idle: Use spin loop primitives for polling idle include/linux/bit_spinlock.h| 5 ++--- include/linux/seqlock.h | 9 - kernel/locking/mcs_spinlock.h | 6 ++ kernel/locking/mutex.c

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Sun, 20 Aug 2017 08:37:36 +0800 kbuild test robot wrote: > Hi Nicholas, > > FYI, the error/warning still remains. Still same answer as before, i.e., it seems to be this toolchain bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21017 I've had no response from

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Sun, 20 Aug 2017 08:37:36 +0800 kbuild test robot wrote: > Hi Nicholas, > > FYI, the error/warning still remains. Still same answer as before, i.e., it seems to be this toolchain bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21017 I've had no response from the microblaze

Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

On Mon, 14 Aug 2017 15:21:48 +1000 Michael Ellerman wrote: > Sukadev Bhattiprolu writes: > > arch/powerpc/include/asm/vas.h | 35 > > arch/powerpc/include/uapi/asm/vas.h | 25 +++ > > I thought we weren't exposing VAS to

Re: [PATCH v6 01/17] powerpc/vas: Define macros, register fields and structures

On Mon, 14 Aug 2017 15:21:48 +1000 Michael Ellerman wrote: > Sukadev Bhattiprolu writes: > > arch/powerpc/include/asm/vas.h | 35 > > arch/powerpc/include/uapi/asm/vas.h | 25 +++ > > I thought we weren't exposing VAS to userspace yet? > > If we are then we need to get things

[PATCH] kernel/watchdog: fix Kconfig constraints for perf hardlockup watchdog

S it seems reasonable to make the dependency explicit. Fixes: 05a4a9527931 ("kernel/watchdog: split up config options") Signed-off-by: Nicholas Piggin <npig...@gmail.com> --- arch/powerpc/Kconfig | 2 +- arch/x86/Kconfig | 2 +- 2 files changed, 2 insertions(+), 2 delet

[PATCH] kernel/watchdog: fix Kconfig constraints for perf hardlockup watchdog

S it seems reasonable to make the dependency explicit. Fixes: 05a4a9527931 ("kernel/watchdog: split up config options") Signed-off-by: Nicholas Piggin --- arch/powerpc/Kconfig | 2 +- arch/x86/Kconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/po

Re: [v4 PATCH 0/2] powerpc/powernv: Enable stop4 via cpuidle

tate on POWER9 via cpuidle. These look good to me, thanks. I think the SPR saving is moving in the right direction too. We should get this enabled stream as soon as possible. For both patches, Reviewed-by: Nicholas Piggin <npig...@gmail.com>

Re: [v4 PATCH 0/2] powerpc/powernv: Enable stop4 via cpuidle

the SPR saving is moving in the right direction too. We should get this enabled stream as soon as possible. For both patches, Reviewed-by: Nicholas Piggin

Re: [PATCH -v2 3/4] locking: Introduce smp_mb__after_spinlock().

ce > > that same barrier _inside_ the spin_lock(). In that case we upgrade > > the RCpc spinlock to an RCsc. That would make all schedule() calls > > fully transitive against one another. > > > > Cc: Alan Stern <st...@rowland.harvard.edu> > > Cc: Nicholas P

Re: [PATCH -v2 3/4] locking: Introduce smp_mb__after_spinlock().

rier _inside_ the spin_lock(). In that case we upgrade > > the RCpc spinlock to an RCsc. That would make all schedule() calls > > fully transitive against one another. > > > > Cc: Alan Stern > > Cc: Nicholas Piggin > > Cc: Ingo Molnar > > Cc: Will Deaco

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 16:32:03 -0700 "Paul E. McKenney" wrote: > On Tue, Aug 01, 2017 at 04:16:54PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 01, 2017 at 06:23:09AM -0700, Paul E. McKenney wrote: > > > On Tue, Aug 01, 2017 at 12:22:03PM +0200, Peter Zijlstra wrote:

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 16:32:03 -0700 "Paul E. McKenney" wrote: > On Tue, Aug 01, 2017 at 04:16:54PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 01, 2017 at 06:23:09AM -0700, Paul E. McKenney wrote: > > > On Tue, Aug 01, 2017 at 12:22:03PM +0200, Peter Zijlstra wrote: > > > > > > [ . . . ] > > >

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 13:00:23 +0200 Peter Zijlstra <pet...@infradead.org> wrote: > On Tue, Aug 01, 2017 at 08:39:28PM +1000, Nicholas Piggin wrote: > > Right, I just don't see what real problem this opens up that you don't > > already have when you are not hard partitioned,

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 13:00:23 +0200 Peter Zijlstra wrote: > On Tue, Aug 01, 2017 at 08:39:28PM +1000, Nicholas Piggin wrote: > > Right, I just don't see what real problem this opens up that you don't > > already have when you are not hard partitioned, therefore it doesn't > &

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 12:22:03 +0200 Peter Zijlstra <pet...@infradead.org> wrote: > On Tue, Aug 01, 2017 at 07:57:17PM +1000, Nicholas Piggin wrote: > > On Tue, 1 Aug 2017 10:12:30 +0200 > > Peter Zijlstra <pet...@infradead.org> wrote: > > > > > On Tue,

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 12:22:03 +0200 Peter Zijlstra wrote: > On Tue, Aug 01, 2017 at 07:57:17PM +1000, Nicholas Piggin wrote: > > On Tue, 1 Aug 2017 10:12:30 +0200 > > Peter Zijlstra wrote: > > > > > On Tue, Aug 01, 2017 at 12:00:47PM +1000, Nicholas

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 10:12:30 +0200 Peter Zijlstra <pet...@infradead.org> wrote: > On Tue, Aug 01, 2017 at 12:00:47PM +1000, Nicholas Piggin wrote: > > Thanks for this, I'll take a look. This should be a good start as a stress > > test, but I'd also be interested in some ap

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 10:12:30 +0200 Peter Zijlstra wrote: > On Tue, Aug 01, 2017 at 12:00:47PM +1000, Nicholas Piggin wrote: > > Thanks for this, I'll take a look. This should be a good start as a stress > > test, but I'd also be interested in some application. T

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 01:33:09 + (UTC) Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote: > - On Jul 31, 2017, at 8:35 PM, Nicholas Piggin npig...@gmail.com wrote: > > > On Mon, 31 Jul 2017 23:20:59 +1000 > > Michael Ellerman <m...@ellerman.id.au> wro

Re: [RFC PATCH v2] membarrier: expedited private command

On Tue, 1 Aug 2017 01:33:09 + (UTC) Mathieu Desnoyers wrote: > - On Jul 31, 2017, at 8:35 PM, Nicholas Piggin npig...@gmail.com wrote: > > > On Mon, 31 Jul 2017 23:20:59 +1000 > > Michael Ellerman wrote: > > > >> Peter Zijlstra writes: > >&g

Re: [RFC PATCH v2] membarrier: expedited private command

On Mon, 31 Jul 2017 23:20:59 +1000 Michael Ellerman wrote: > Peter Zijlstra writes: > > > On Fri, Jul 28, 2017 at 10:55:32AM +0200, Peter Zijlstra wrote: > >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c > >> index

Re: [RFC PATCH v2] membarrier: expedited private command

On Mon, 31 Jul 2017 23:20:59 +1000 Michael Ellerman wrote: > Peter Zijlstra writes: > > > On Fri, Jul 28, 2017 at 10:55:32AM +0200, Peter Zijlstra wrote: > >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c > >> index e9785f7aed75..33f34a201255 100644 > >> --- a/kernel/sched/core.c >

Re: [RFC PATCH v2] membarrier: expedited private command

On Sat, 29 Jul 2017 19:45:43 +1000 Nicholas Piggin <npig...@gmail.com> wrote: > hmm, we might be able to restrict iteration > to mm_cpumask(current->mm), no? Oh that's been discussed too. I'll read back over it too.

Re: [RFC PATCH v2] membarrier: expedited private command

On Sat, 29 Jul 2017 19:45:43 +1000 Nicholas Piggin wrote: > hmm, we might be able to restrict iteration > to mm_cpumask(current->mm), no? Oh that's been discussed too. I'll read back over it too.

Re: [RFC PATCH v2] membarrier: expedited private command

On Sat, 29 Jul 2017 11:23:33 +0200 Peter Zijlstra <pet...@infradead.org> wrote: > On Sat, Jul 29, 2017 at 11:58:40AM +1000, Nicholas Piggin wrote: > > I haven't had time to read the thread and understand exactly why you need > > this extra barrier, I'll do it next week.

Re: [RFC PATCH v2] membarrier: expedited private command

On Sat, 29 Jul 2017 11:23:33 +0200 Peter Zijlstra wrote: > On Sat, Jul 29, 2017 at 11:58:40AM +1000, Nicholas Piggin wrote: > > I haven't had time to read the thread and understand exactly why you need > > this extra barrier, I'll do it next week. Thanks for cc'ing us on it

Re: [RFC PATCH v2] membarrier: expedited private command

On Fri, 28 Jul 2017 17:06:53 + (UTC) Mathieu Desnoyers wrote: > - On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: > >> > Which only leaves PPC stranded..

Re: [RFC PATCH v2] membarrier: expedited private command

On Fri, 28 Jul 2017 17:06:53 + (UTC) Mathieu Desnoyers wrote: > - On Jul 28, 2017, at 12:46 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Fri, Jul 28, 2017 at 03:38:15PM +, Mathieu Desnoyers wrote: > >> > Which only leaves PPC stranded.. but the 'good' news is that mpe

Re: [RESEND] [v3 PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

d only when we are offlining the CPU and set it > back once the CPU is online. Looks pretty good to me, thanks! Reviewed-by: Nicholas Piggin <npig...@gmail.com> > > Signed-off-by: Gautham R. Shenoy <e...@linux.vnet.ibm.com> > --- > v2 --> v3: > - Program the LPCR

Re: [RESEND] [v3 PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

once the CPU is online. Looks pretty good to me, thanks! Reviewed-by: Nicholas Piggin > > Signed-off-by: Gautham R. Shenoy > --- > v2 --> v3: > - Program the LPCR during platform idle entry/exit on both POWER8 and > POWER9 > > v1 --> v2: > - Mov

Re: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

before entering stop. > > Signed-off-by: Gautham R. Shenoy <e...@linux.vnet.ibm.com> Looks good to me. Keeping in mind we need to tidy up and unify all this SPR handling and save/restore etc. in the longer term. Reviewed-by: Nicholas Piggin <npig...@gmail.com> > --- &

Re: [v3 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

. Shenoy Looks good to me. Keeping in mind we need to tidy up and unify all this SPR handling and save/restore etc. in the longer term. Reviewed-by: Nicholas Piggin > --- > v2-->v3: > - Use a structure instead of an array for the stop sprs save area. > - Name the offsets into the paca

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Sun, 23 Jul 2017 08:20:30 +0800 kbuild test robot wrote: > Hi Nicholas, > > FYI, the error/warning still remains. FYI, I still suspect it is this bug https://sourceware.org/bugzilla/show_bug.cgi?id=21017 If so, then I'm not sure if it can be worked around in Linux.

Re: undefined reference to `_GLOBAL_OFFSET_TABLE_'

On Sun, 23 Jul 2017 08:20:30 +0800 kbuild test robot wrote: > Hi Nicholas, > > FYI, the error/warning still remains. FYI, I still suspect it is this bug https://sourceware.org/bugzilla/show_bug.cgi?id=21017 If so, then I'm not sure if it can be worked around in Linux. Thanks, Nick > >

Re: [v2 PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

LPCR, lpcr_val); > + if (cpu_has_feature(CPU_FTR_ARCH_300)) > + opal_slw_set_reg(pir, SPRN_LPCR, lpcr_val); Is opal_slw_set_reg very heavyweight? If not, I would just remove the POWER9 special casing entirely from both these functions, which follows the principle of least surprise. Otherwise I guess it's reasonable. Thanks for making those other changes, it looks good. Reviewed-by: Nicholas Piggin <npig...@gmail.com>

Re: [v2 PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

_set_reg(pir, SPRN_LPCR, lpcr_val); Is opal_slw_set_reg very heavyweight? If not, I would just remove the POWER9 special casing entirely from both these functions, which follows the principle of least surprise. Otherwise I guess it's reasonable. Thanks for making those other changes, it looks good. Reviewed-by: Nicholas Piggin

Re: [v2 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300) > hypervisor_state_restored: > Also perhaps just a little comment in the code explaining why power8 does not need this because it only uses it for hotplug as you do in the changelog would help when reading the code. Sorry I didn't pick this up on your v1 patches. If you change those minor things, please add Reviewed-by: Nicholas Piggin <npig...@gmail.com> Thanks, Nick

Re: [v2 PATCH 1/2] powernv/powerpc:Save/Restore additional SPRs for stop4 cpuidle

o perhaps just a little comment in the code explaining why power8 does not need this because it only uses it for hotplug as you do in the changelog would help when reading the code. Sorry I didn't pick this up on your v1 patches. If you change those minor things, please add Reviewed-by: Nicholas Piggin Thanks, Nick

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

On Wed, 19 Jul 2017 10:34:59 +0530 Gautham R Shenoy <e...@linux.vnet.ibm.com> wrote: > Hello Nicholas, > > On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote: > > Thanks for working on these patches. We really need to get this stuff > > merged and tested

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

On Wed, 19 Jul 2017 10:34:59 +0530 Gautham R Shenoy wrote: > Hello Nicholas, > > On Wed, Jul 19, 2017 at 12:14:12PM +1000, Nicholas Piggin wrote: > > Thanks for working on these patches. We really need to get this stuff > > merged and tested asap :) > > > &g

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

Thanks for working on these patches. We really need to get this stuff merged and tested asap :) On Tue, 18 Jul 2017 19:58:49 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > > Currently we use the stop-api provided by the

Re: [PATCH 2/2] powernv/powerpc: Clear PECE1 in LPCR via stop-api only on Hotplug

Thanks for working on these patches. We really need to get this stuff merged and tested asap :) On Tue, 18 Jul 2017 19:58:49 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > > Currently we use the stop-api provided by the firmware to program the > SLW engine to restore the

Re: parisc:generic-64bit_defconfig build failures due to 'kbuild: handle libs-y archives separately...'

why 0day didn't catch it. Does it build test parisc/generic-64bit_defconfig, I wonder? Thanks, Nick > > Ursprüngliche Nachricht > Von: Guenter Roeck <li...@roeck-us.net> > Datum: 18.07.17 17:21 (GMT+01:00) > An: Nicholas Piggin <npig...@gmail.com> >

Re: parisc:generic-64bit_defconfig build failures due to 'kbuild: handle libs-y archives separately...'

parisc/generic-64bit_defconfig, I wonder? Thanks, Nick > > Ursprüngliche Nachricht > Von: Guenter Roeck > Datum: 18.07.17 17:21 (GMT+01:00) > An: Nicholas Piggin > Cc: linux-kernel@vger.kernel.org, Masahiro Yamada > , "James E.J. Bo

Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

On Wed, 12 Jul 2017 09:29:40 -0700 Andi Kleen <a...@firstfloor.org> wrote: > Nicholas Piggin <npig...@gmail.com> writes: > >> > >> I think we should aim for gc-sections to be used by default and have LTO > >> as a possible option only. > >

Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

On Wed, 12 Jul 2017 09:29:40 -0700 Andi Kleen wrote: > Nicholas Piggin writes: > >> > >> I think we should aim for gc-sections to be used by default and have LTO > >> as a possible option only. > > > > I agree after it starts getting implemented

Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

On Sun, 9 Jul 2017 09:59:44 -0400 (EDT) Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Sun, 9 Jul 2017, Masahiro Yamada wrote: > > > Hi. > > > > 2017-07-09 18:05 GMT+09:00 Ingo Molnar <mi...@kernel.org>: > > > > > > * Nichola

Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

On Sun, 9 Jul 2017 09:59:44 -0400 (EDT) Nicolas Pitre wrote: > On Sun, 9 Jul 2017, Masahiro Yamada wrote: > > > Hi. > > > > 2017-07-09 18:05 GMT+09:00 Ingo Molnar : > > > > > > * Nicholas Piggin wrote: > > > > > >>

[RFC PATCH] x86: enable dead code and data elimination (LTO)

Allow x86 to select DCDE option under CONFIG_EXPERT to reduce binary size. This is an RFC only for ~4.14/15 kernel. Sending as a single patch to make it easy to review and test for x86, and give other archs a base to look at. This is a _relatively_ simple and low overhead first step to getting

[RFC PATCH] x86: enable dead code and data elimination (LTO)

Allow x86 to select DCDE option under CONFIG_EXPERT to reduce binary size. This is an RFC only for ~4.14/15 kernel. Sending as a single patch to make it easy to review and test for x86, and give other archs a base to look at. This is a _relatively_ simple and low overhead first step to getting

Re: [PATCH 5/5] powernv:idle: Disable LOSE_FULL_CONTEXT states when stop-api fails.

On Fri, 7 Jul 2017 23:07:10 +0530 Gautham R Shenoy <e...@linux.vnet.ibm.com> wrote: > On Fri, Jul 07, 2017 at 01:29:16AM +1000, Nicholas Piggin wrote: > > On Wed, 5 Jul 2017 22:08:16 +0530 > > "Gautham R. Shenoy" <e...@linux.vnet.ibm.com> wrote: >

Re: [PATCH 5/5] powernv:idle: Disable LOSE_FULL_CONTEXT states when stop-api fails.

On Fri, 7 Jul 2017 23:07:10 +0530 Gautham R Shenoy wrote: > On Fri, Jul 07, 2017 at 01:29:16AM +1000, Nicholas Piggin wrote: > > On Wed, 5 Jul 2017 22:08:16 +0530 > > "Gautham R. Shenoy" wrote: > > > > > From: "Gautham R. Shenoy&q

Re: [PATCH 4/5] powernv:idle: Move initialization of sibling pacas to pnv_alloc_idle_core_states

On Fri, 7 Jul 2017 20:34:16 +0530 Gautham R Shenoy <e...@linux.vnet.ibm.com> wrote: > On Fri, Jul 07, 2017 at 01:16:09AM +1000, Nicholas Piggin wrote: > > On Wed, 5 Jul 2017 22:08:15 +0530 > > "Gautham R. Shenoy" <e...@linux.vnet.ibm.com> wrote: >

Re: [PATCH 4/5] powernv:idle: Move initialization of sibling pacas to pnv_alloc_idle_core_states

On Fri, 7 Jul 2017 20:34:16 +0530 Gautham R Shenoy wrote: > On Fri, Jul 07, 2017 at 01:16:09AM +1000, Nicholas Piggin wrote: > > On Wed, 5 Jul 2017 22:08:15 +0530 > > "Gautham R. Shenoy" wrote: > > > > > From: "Gautham R. Shenoy"

Re: [PATCH 1/5] powernv:idle: Move device-tree parsing to one place.

On Fri, 7 Jul 2017 16:55:39 +0530 Gautham R Shenoy <e...@linux.vnet.ibm.com> wrote: > Hello Nicholas, > > On Fri, Jul 07, 2017 at 12:53:40AM +1000, Nicholas Piggin wrote: > > I wouldn't have the wrapper function... but it's your code so it's > > up to you. One thing t

Re: [PATCH 1/5] powernv:idle: Move device-tree parsing to one place.

On Fri, 7 Jul 2017 16:55:39 +0530 Gautham R Shenoy wrote: > Hello Nicholas, > > On Fri, Jul 07, 2017 at 12:53:40AM +1000, Nicholas Piggin wrote: > > I wouldn't have the wrapper function... but it's your code so it's > > up to you. One thing though is that this function

Re: [PATCH 5/5] powernv:idle: Disable LOSE_FULL_CONTEXT states when stop-api fails.

On Wed, 5 Jul 2017 22:08:16 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > Currently, we use the opal call opal_slw_set_reg() to inform the that > the Sleep-Winkle Engine (SLW) to restore the contents of some of the >

Re: [PATCH 5/5] powernv:idle: Disable LOSE_FULL_CONTEXT states when stop-api fails.

On Wed, 5 Jul 2017 22:08:16 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > Currently, we use the opal call opal_slw_set_reg() to inform the that > the Sleep-Winkle Engine (SLW) to restore the contents of some of the > Hypervisor state on wakeup from deep idle states that

Re: [PATCH 4/5] powernv:idle: Move initialization of sibling pacas to pnv_alloc_idle_core_states

these guys? Nothing good I think. Perhaps we should put them into the pacas or somewhere in bolted memory. Good cleanup though. Reviewed-by: Nicholas Piggin <npig...@gmail.com>

Re: [PATCH 4/5] powernv:idle: Move initialization of sibling pacas to pnv_alloc_idle_core_states

move the thread_sibling_pacas allocation to here? Speaking of which... core_idle_state and thread_sibling_pacas are allocated with kmalloc_node... What happens if we take an SLB miss in the idle wakeup code on these guys? Nothing good I think. Perhaps we should put them into the pacas or somewhere in bolted memory. Good cleanup though. Reviewed-by: Nicholas Piggin

Re: [PATCH 3/5] powernv:idle: Define idle init function for power8

(unsigned int *)pnv_fastsleep_workaround_at_entry, > - PPC_INST_NOP); > - patch_instruction( > - (unsigned int *)pnv_fastsleep_workaround_at_exit, > - PPC_INST_NOP); So previously this would run on POWER9 and patch out those branches. But POWER9 never runs that code, so no problem. Good cleanup. Reviewed-by: Nicholas Piggin <npig...@gmail.com>

Re: [PATCH 3/5] powernv:idle: Define idle init function for power8

PPC_INST_NOP); > - patch_instruction( > - (unsigned int *)pnv_fastsleep_workaround_at_exit, > - PPC_INST_NOP); So previously this would run on POWER9 and patch out those branches. But POWER9 never runs that code, so no problem. Good cleanup. Reviewed-by: Nicholas Piggin

Re: [PATCH 2/5] powernv:idle: Change return type of pnv_probe_idle_states to int

from void to > int and in case of failures, bail out early on in > pnv_init_idle_states. > > Signed-off-by: Gautham R. Shenoy <e...@linux.vnet.ibm.com> Looks good to me. Reviewed-by: Nicholas Piggin <npig...@gmail.com> I wonder if the warnings are strong enough here to l

Re: [PATCH 2/5] powernv:idle: Change return type of pnv_probe_idle_states to int

; pnv_init_idle_states. > > Signed-off-by: Gautham R. Shenoy Looks good to me. Reviewed-by: Nicholas Piggin I wonder if the warnings are strong enough here to let people know idle won't be used so power consumption will be high and performance significantly reduced on SMT machines?

Re: [PATCH 1/5] powernv:idle: Move device-tree parsing to one place.

On Wed, 5 Jul 2017 22:08:12 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > The details of the platform idle state are exposed by the firmware to > the kernel via device tree. > > In the current code, we parse the device tree

Re: [PATCH 1/5] powernv:idle: Move device-tree parsing to one place.

On Wed, 5 Jul 2017 22:08:12 +0530 "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > The details of the platform idle state are exposed by the firmware to > the kernel via device tree. > > In the current code, we parse the device tree twice : > > 1) During the boot up in

Re: [PATCH] cpuidle: menu: allow state 0 to be disabled

On Thu, 29 Jun 2017 22:57:33 +0200 "Rafael J. Wysocki" <raf...@kernel.org> wrote: > On Mon, Jun 26, 2017 at 7:38 AM, Nicholas Piggin <npig...@gmail.com> wrote: > > The menu driver does not allow state0 to be disabled completely. > > If it is disabled but ot

Re: [PATCH] cpuidle: menu: allow state 0 to be disabled

On Thu, 29 Jun 2017 22:57:33 +0200 "Rafael J. Wysocki" wrote: > On Mon, Jun 26, 2017 at 7:38 AM, Nicholas Piggin wrote: > > The menu driver does not allow state0 to be disabled completely. > > If it is disabled but other enabled states don't meet latency > >

[PATCH] powerpc/64s: watchdog false positive warning at CPU unplug

nto...@in.ibm.com> Signed-off-by: Nicholas Piggin <npig...@gmail.com> --- arch/powerpc/kernel/watchdog.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c index d46040c0da40..93395a53336b 100644 --- a/arch/po

[PATCH] powerpc/64s: watchdog false positive warning at CPU unplug

-by: Nicholas Piggin --- arch/powerpc/kernel/watchdog.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c index d46040c0da40..93395a53336b 100644 --- a/arch/powerpc/kernel/watchdog.c +++ b/arch/powerpc/kernel

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Fri, 30 Jun 2017 10:52:18 +0530 Abdul Haleem <abdha...@linux.vnet.ibm.com> wrote: > On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote: > > On Thu, 29 Jun 2017 20:23:05 +1000 > > Nicholas Piggin <npig...@gmail.com> wrote: > > > > > On Thu,

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Fri, 30 Jun 2017 10:52:18 +0530 Abdul Haleem wrote: > On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote: > > On Thu, 29 Jun 2017 20:23:05 +1000 > > Nicholas Piggin wrote: > > > > > On Thu, 29 Jun 2017 19:36:14 +1000 > > > Nicholas Pig

Re: Build failure in -next due to 'sh: thin archives fix linking'

On Fri, 30 Jun 2017 00:36:42 +0900 Masahiro Yamada <yamada.masah...@socionext.com> wrote: > Hi. > > 2017-06-28 23:02 GMT+09:00 Guenter Roeck <li...@roeck-us.net>: > > On 06/28/2017 05:58 AM, Nicholas Piggin wrote: > >> > >> On Wed, 28 Jun 2017 0

Re: Build failure in -next due to 'sh: thin archives fix linking'

On Fri, 30 Jun 2017 00:36:42 +0900 Masahiro Yamada wrote: > Hi. > > 2017-06-28 23:02 GMT+09:00 Guenter Roeck : > > On 06/28/2017 05:58 AM, Nicholas Piggin wrote: > >> > >> On Wed, 28 Jun 2017 05:38:50 -0700 > >> Guenter Roeck wrote: > >>

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Thu, 29 Jun 2017 20:23:05 +1000 Nicholas Piggin <npig...@gmail.com> wrote: > On Thu, 29 Jun 2017 19:36:14 +1000 > Nicholas Piggin <npig...@gmail.com> wrote: > > I don't *think* the replay-wakeup-interrupt patch is directly involved, but > > it's likely to be on

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Thu, 29 Jun 2017 20:23:05 +1000 Nicholas Piggin wrote: > On Thu, 29 Jun 2017 19:36:14 +1000 > Nicholas Piggin wrote: > > I don't *think* the replay-wakeup-interrupt patch is directly involved, but > > it's likely to be one of the idle patches. Okay this turned out t

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Thu, 29 Jun 2017 19:36:14 +1000 Nicholas Piggin <npig...@gmail.com> wrote: > I've seen this as well (or something like it) in mambo at boot, but > it's pretty rare to hit. I'm trying to debug it. > > I'm guessing possibly an idle vs interrupt race. > > > [ 4255.151

Re: [linux-next] cpus stalls detected few hours after booting next kernel

On Thu, 29 Jun 2017 19:36:14 +1000 Nicholas Piggin wrote: > I've seen this as well (or something like it) in mambo at boot, but > it's pretty rare to hit. I'm trying to debug it. > > I'm guessing possibly an idle vs interrupt race. > > > [ 4255.151192] Sending NMI

Re: [linux-next] cpus stalls detected few hours after booting next kernel

I've seen this as well (or something like it) in mambo at boot, but it's pretty rare to hit. I'm trying to debug it. I'm guessing possibly an idle vs interrupt race. > [ 4255.151192] Sending NMI from CPU 5 to CPUs 0: > [ 4255.151246] NMI backtrace for cpu 0 > [ 4255.151287] CPU: 0 PID: 0 Comm:

Re: [linux-next] cpus stalls detected few hours after booting next kernel

I've seen this as well (or something like it) in mambo at boot, but it's pretty rare to hit. I'm trying to debug it. I'm guessing possibly an idle vs interrupt race. > [ 4255.151192] Sending NMI from CPU 5 to CPUs 0: > [ 4255.151246] NMI backtrace for cpu 0 > [ 4255.151287] CPU: 0 PID: 0 Comm:

Re: Build failure in -next due to 'sh: thin archives fix linking'

On Wed, 28 Jun 2017 05:38:50 -0700 Guenter Roeck wrote: > Hi, > > I see the following build error in -next when building > sh:rts7751r2dplus_defconfig. > > sh4-linux-ld: arch/sh/kernel/vsyscall/vsyscall-dummy.o: compiled for a big > endian system and target is little

Re: Build failure in -next due to 'sh: thin archives fix linking'

On Wed, 28 Jun 2017 05:38:50 -0700 Guenter Roeck wrote: > Hi, > > I see the following build error in -next when building > sh:rts7751r2dplus_defconfig. > > sh4-linux-ld: arch/sh/kernel/vsyscall/vsyscall-dummy.o: compiled for a big > endian system and target is little endian > sh4-linux-ld:

<    5   6   7   8   9   10   11   12   13   14   >