Re: [RFC v2 1/3] hotplug/mobility: Apply assoc updates for Post Migration Topo

On 04/24/2018 04:33 PM, Michael Bringmann wrote: > See comments below: > > On 04/24/2018 11:56 AM, Nathan Fontenot wrote: >> On 02/26/2018 02:52 PM, Michael Bringmann wrote: >>> hotplug/mobility: Recognize more changes to the associativity of >>> memory blocks described by the

Re: [RFC v2 3/3] postmigration/memory: Associativity & ibm,dynamic-memory-v2

On 04/24/2018 04:35 PM, Michael Bringmann wrote: > See below. > > On 04/24/2018 12:17 PM, Nathan Fontenot wrote: >> On 02/26/2018 02:53 PM, Michael Bringmann wrote: >>> postmigration/memory: Now apply changes to the associativity of memory >>> blocks described by the 'ibm,dynamic-memory-v2'

Re: [PATCH 4/6] powerpc/64s: Enable barrier_nospec based on firmware settings

Hello, On Tue, 24 Apr 2018 14:15:57 +1000 Michael Ellerman wrote: > From: Michal Suchanek > > Check what firmware told us and enable/disable the barrier_nospec as > appropriate. > > We err on the side of enabling the barrier, as it's no-op on older >

Re: OOM killer invoked while still one forth of mem is available

On Thu 26-04-18 15:28:46, Christophe LEROY wrote: > > > Le 26/04/2018 à 15:11, Michal Hocko a écrit : > > On Thu 26-04-18 08:10:30, Christophe LEROY wrote: > > > > > > > > > Le 25/04/2018 à 21:57, David Rientjes a écrit : > > > > On Tue, 24 Apr 2018, christophe leroy wrote: > > > > > > > > >

[PATCH 3/4] dt-bindings: powerpc/4xx: move 4xx NDFC and EMAC bindings to subsystem directories

Bindings are supposed to be organized by device class/function. Move a couple of powerpc 4xx bindings to the correct binding directory. Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Rob Herring --- .../devicetree/bindings/{powerpc/4xx/ndfc.txt => mtd/ibm,ndfc.txt}| 0

Re: [PATCH 2/6] powerpc/64s: Add support for ori barrier_nospec patching

Hello, On Tue, 24 Apr 2018 14:15:55 +1000 Michael Ellerman wrote: > From: Michal Suchanek > > Based on the RFI patching. This is required to be able to disable the > speculation barrier. why do you not patch the nospec barrier which is included as part

[PATCH] powerpc: paste - Mask XERSO bit in CR

NX can set 3rd bit in CR register for XER[SO] (Summation overflow) which is not used for paste return value. So. mask this bit to get proper return status. Signed-off-by: Haren Myneni diff --git a/arch/powerpc/platforms/powernv/copy-paste.h

[PATCH] powerpc: Add NVDIMM to powernv_defconfig

This enables greater testing NVDIMMs as it becomes more prevalent. This is also the minimal required to enable persistent memory in mambo. This adds 100KB to the kernel text and 170KB to the vmlinux Signed-off-by: Michael Neuling --- arch/powerpc/configs/powernv_defconfig |

Re: OOM killer invoked while still one forth of mem is available

Le 25/04/2018 à 21:57, David Rientjes a écrit : On Tue, 24 Apr 2018, christophe leroy wrote: Hi Allthough there is still about one forth of memory available (7976kB among 32MB), oom-killer is invoked and makes a victim. What could be the reason and how could it be solved ? [ 54.400754]

Re: [PATCH] powerpc: Fix smp_send_stop NMI IPI handling

Nicholas Piggin writes: > On Wed, 25 Apr 2018 13:15:34 +1000 > Michael Ellerman wrote: >> Nicholas Piggin writes: >> >> > The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count >> > over the handler function call, which

Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation

On 25/04/18 07:12, Sukadev Bhattiprolu wrote: Yes. Like with PIDR, was trying to assign TIDR initially to all threads. But since only a subset of threads need/use TIDR, we can assign the value later (when set_thread_tidr() is called). So we should be able to use task_pid_nr() then. OK.

[PATCH v2] powerpc: Fix deadlock with multiple calls to smp_send_stop

smp_send_stop can lock up the IPI path for any subsequent calls, because the receiving CPUs spin in their handler function. This started becoming a problem with the addition of an smp_send_stop call in the reboot path, because panics can reboot after doing their own smp_send_stop. The NMI IPI

Re: [PATCH 01/11] KVM: PPC: add pt_regs into kvm_vcpu_arch and move vcpu->arch.gpr[] into it

Hi Simon, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH] powerpc/eeh: Avoid misleading message "EEH: no capable adapters found"

On Thu, 2018-03-22 at 23:10 -0300, Mauro S. M. Rodrigues wrote: > Due to recent refactoring in EEH in: > commit b9fde58db7e5 ("powerpc/powernv: Rework EEH initialization on > powernv") > a misleading message was seen in the kernel message buffer: > > [0.108431] EEH: PowerNV platform

Re: [2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

On Tue, 2018-04-10 at 11:49:32 UTC, Nicholas Piggin wrote: > The OPAL RTC driver does not sleep in case it gets OPAL_BUSY or > OPAL_BUSY_EVENT from firmware, which causes large scheduling > latencies, up to 50 seconds have been observed here when RTC stops > responding (BMC reboot can do it). > >

Re: [v3] powerpc: Fix smp_send_stop NMI IPI handling

On Thu, 2018-04-26 at 10:19:02 UTC, Michael Ellerman wrote: > From: Nicholas Piggin > > The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count > over the handler function call, which causes later smp_send_nmi_ipi() > callers to spin until the call is finished. >

Re: [PATCH v2] powerpc: Fix smp_send_stop NMI IPI handling

Nicholas Piggin writes: > The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count > over the handler function call, which causes later smp_send_nmi_ipi() > callers to spin until the call is finished. > > The smp_send_stop function never returns, so the busy count

[PATCH v3] powerpc: Fix smp_send_stop NMI IPI handling

From: Nicholas Piggin The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count over the handler function call, which causes later smp_send_nmi_ipi() callers to spin until the call is finished. The stop_this_cpu() function never returns, so the busy count is never

Re: [PATCH v2 9/9] powerpc/hugetlb: Enable hugetlb migration for ppc64

Le 16/05/2017 à 11:23, Aneesh Kumar K.V a écrit : Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/platforms/Kconfig.cputype | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/platforms/Kconfig.cputype

Re: [PATCH v5 1/4] powerpc/fadump: un-register fadump on kexec path.

On Thu, 26 Apr 2018 17:12:03 +0530 Mahesh J Salgaonkar wrote: > From: Mahesh Salgaonkar > > otherwise the fadump registration in new kexec-ed kernel complains that > fadump is already registered. This makes new kernel to continue using >

[RFC PATCH 6/9] powerpc: mm: migrate: add pmd swap entry to support thp migration.

From: Zi Yan pmd swap soft dirty support is added, too. Signed-off-by: Zi Yan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Aneesh Kumar K.V"

[PATCH v5 0/4] powerpc/fadump: Improvements and fixes for firmware-assisted dump.

One of the primary issues with Firmware Assisted Dump (fadump) on Power is that it needs a large amount of memory to be reserved. This reserved memory is used for saving the contents of old crashed kernel's memory before fadump capture kernel uses old kernel's memory area to boot. However, This

Re: [PATCH v2] powerpc: Fix smp_send_stop NMI IPI handling

On Thu, 26 Apr 2018 20:30:37 +1000 Michael Ellerman wrote: > Nicholas Piggin writes: > > The NMI IPI handler for a receiving CPU increments nmi_ipi_busy_count > > over the handler function call, which causes later smp_send_nmi_ipi() > > callers to spin

Re: OOM killer invoked while still one forth of mem is available

Le 26/04/2018 à 15:11, Michal Hocko a écrit : On Thu 26-04-18 08:10:30, Christophe LEROY wrote: Le 25/04/2018 à 21:57, David Rientjes a écrit : On Tue, 24 Apr 2018, christophe leroy wrote: Hi Allthough there is still about one forth of memory available (7976kB among 32MB), oom-killer is

[PATCH v5 1/4] powerpc/fadump: un-register fadump on kexec path.

From: Mahesh Salgaonkar otherwise the fadump registration in new kexec-ed kernel complains that fadump is already registered. This makes new kernel to continue using fadump registered by previous kernel which may lead to invalid vmcore generation. Hence this patch

[PATCH v5 2/4] powerpc/fadump: Reservationless firmware assisted dump

From: Mahesh Salgaonkar One of the primary issues with Firmware Assisted Dump (fadump) on Power is that it needs a large amount of memory to be reserved. On large systems with TeraBytes of memory, this reservation can be quite significant. In some cases, fadump fails

[PATCH] powerpc/kvm/booke: fix altivec related build break

From: Laurentiu Tudor Add missing "altivec unavailable" interrupt injection helper thus fixing the linker error below: arch/powerpc/kvm/emulate_loadstore.o: In function `kvmppc_check_altivec_disabled': arch/powerpc/kvm/emulate_loadstore.c: undefined reference to

Re: OOM killer invoked while still one forth of mem is available

On Thu 26-04-18 08:10:30, Christophe LEROY wrote: > > > Le 25/04/2018 à 21:57, David Rientjes a écrit : > > On Tue, 24 Apr 2018, christophe leroy wrote: > > > > > Hi > > > > > > Allthough there is still about one forth of memory available (7976kB > > > among 32MB), oom-killer is invoked and

Re: [PATCH v5 1/4] powerpc/fadump: un-register fadump on kexec path.

On Thu, 26 Apr 2018 18:35:10 +0530 Mahesh Jagannath Salgaonkar wrote: > On 04/26/2018 06:28 PM, Nicholas Piggin wrote: > > On Thu, 26 Apr 2018 17:12:03 +0530 > > Mahesh J Salgaonkar wrote: > > > >> From: Mahesh Salgaonkar

[PATCH v5 4/4] powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.

From: Mahesh Salgaonkar For fadump to work successfully there should not be any holes in reserved memory ranges where kernel has asked firmware to move the content of old kernel memory in event of crash. Now that fadump uses CMA for reserved area, this memory area is

Re: [PATCH v5 1/4] powerpc/fadump: un-register fadump on kexec path.

On 04/26/2018 06:28 PM, Nicholas Piggin wrote: > On Thu, 26 Apr 2018 17:12:03 +0530 > Mahesh J Salgaonkar wrote: > >> From: Mahesh Salgaonkar >> >> otherwise the fadump registration in new kexec-ed kernel complains that >> fadump is already

[PATCH v5 3/4] powerpc/fadump: throw proper error message on fadump registration failure.

From: Mahesh Salgaonkar fadump fails to register when there are holes in reserved memory area. This can happen if user has hot-removed a memory that falls in the fadump reserved memory area. Throw a meaningful error message to the user in such case. Signed-off-by:

[RFC PATCH 0/9] Enable THP migration for all possible architectures

From: Zi Yan Hi all, THP migration is only enabled on x86_64 with a special ARCH_ENABLE_THP_MIGRATION macro. This patchset enables THP migration for all architectures that uses transparent hugepage, so that special macro can be dropped. Instead, THP migration is

Re: [PATCH 1/3] powerpc/nohash: remove hash related code from nohash headers.

Hi Christophe, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v4.17-rc2 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[RFC PATCH 9/9] mm: migrate: enable thp migration for all possible architectures.

From: Zi Yan Remove CONFIG_ARCH_ENABLE_THP_MIGRATION. thp migration is enabled along with transparent hugepage and can be toggled via /sys/kernel/mm/transparent_hugepage/enable_thp_migration. Signed-off-by: Zi Yan Cc: linux...@kvack.org Cc: Vineet

Re: OOM killer invoked while still one forth of mem is available

Michal Hocko a écrit : On Thu 26-04-18 15:28:46, Christophe LEROY wrote: Le 26/04/2018 à 15:11, Michal Hocko a écrit : > On Thu 26-04-18 08:10:30, Christophe LEROY wrote: > > > > > > Le 25/04/2018 à 21:57, David Rientjes a écrit : > > > On Tue, 24 Apr 2018, christophe