On 11/02/2015 02:51 PM, John Allen wrote:
> This patch fixes a bug where a kernel warning is triggered when performing
> a memory hotplug on ppc64. This warning may also occur on any architecture
> that has multiple sections per memory block.
>
> [ 78.300767] ---
ore to reserve memory,
this can interrupt the memory reservation process. This patch modifies
memory_probe_store to take the hotplug sysfs lock to prevent the online
of added memory before the completion of the probe.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
v2: Move call to unlock_d
ore to reserve memory,
this can interrupt the memory reservation process. This patch modifies
memory_probe_store to take the hotplug sysfs lock to prevent the online
of added memory before the completion of the probe.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/drivers/ba
add a block of memory with
a single call to add_memory as opposed to looping through and adding
each section individually. A single call to add_memory is protected by
the mem_hotplug mutex which will prevent the udev rule from onlining
memory until the reservation of the entire block is c
add a block of memory with
a single call to add_memory as opposed to looping through and adding
each section individually. A single call to add_memory is protected by
the mem_hotplug mutex which will prevent the udev rule from onlining
memory until the reservation of the entire block is c
Hi Michael,
On 11/09/2015 07:21 PM, Michael Ellerman wrote:
> Hi John,
>
> On Tue, 2015-11-03 at 11:21 -0600, John Allen wrote:
>> This patch fixes a bug where a kernel warning is triggered when performing
>> a memory hotplug on ppc64. This warning may also occur on any arc
, ibmvnic_xmit will return NETDEV_TX_BUSY and stop the current tx
queue. Subsequently, the queue will be restarted in ibmvnic_complete_tx
when all pending tx completion requests have been cleared.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/drivers/net/ethernet/ibm/ibm
On 04/12/2016 03:12 PM, Eric Dumazet wrote:
> On Tue, 2016-04-12 at 14:38 -0500, John Allen wrote:
>> Moves tx completion processing out of interrupt context, deferring work
>> using a wait queue. With this work now deferred, we must account for the
>> possibility that skbs ca
requesting fewer scrqs.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index 21bccf6..6e9b91d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -800,11 +
and that proper serialization is maintained during the PRRN event.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/pla
and serialized properly.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c | 52
1 file changed, 52 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 2
Add handler for new hotplug interrupt. For memory and CPU hotplug events,
we will add the hotplug errorlog to the hotplug workqueue. Since PCI
hotplug is not currently supported in the kernel, PCI hotplug events are
written to the rtas_log_bug and are handled by rtas_errd.
Signed-off-by: John
are handled and serialized properly.
---
John Allen (3):
powerpc/pseries: Add pseries hotplug workqueue
powerpc/pseries: Add support for hotplug interrupt source
powerpc/pseries: Use kernel hotplug queue for PowerVM hotplug events
arch/powerpc/platforms/pseries/dlpar.c | 57
I forgot to run this series through checkpatch before sending. Looks like there
are some various whitespace errors. Will fix these and send with v2 after any
comments on the patches.
On 07/06/2016 10:44 AM, John Allen wrote:
> This series introduces a new workqueue for handling hotplug eve
by: Nathan Fontenot <nf...@linux.vnet.ibm.com>
> ---
Reviewed-by: John Allen <jal...@linux.vnet.ibm.com>
ot <nf...@linux.vnet.ibm.com>
> ---
Reviewed-by: John Allen <jal...@linux.vnet.ibm.com>
> strsep() and sysfs_streq() routines to parse the buffer. This also
> separates the parsing code into subroutines to make cleaner.
>
> Signed-off-by: Nathan Fontenot <nf...@linux.vnet.ibm.com>
> ---
Reviewed-by: John Allen <jal...@linux.vnet.ibm.com>
operation on the hotplug queue for any phandle included in the PRRN event
that is determined to be an LMB.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index a26a020..8836130 100644
--- a/arch/powerpc/kernel/rtasd.c
-by: Nathan Fontenot <nf...@linux.vnet.ibm.com>
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 34 +++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memo
longer use the return code from the hotplug event, remove the
wait_for_completion infrastructure.
John Allen (3):
powerpc/pseries: Make the acquire/release of the drc for memory a
seperate step
powerpc/pseries: Introduce memory hotplug READD operation
powerpc/pseries: Update affinity
from another source and grab the hotplug lock preventing the hot
add from occurring. To prevent this situation, this patch introduces the
notion of a hot "readd" action for memory which atomizes a hot remove and
a hot add into a single, serialized operation on the hotplug queue.
Signed-of
,
memory hotplug was not included in the kernel. Since memory hotplug is now
available, this patchset moves the PRRN topology updating into the kernel.
John Allen (2):
powerpc/pseries: Introduce memory hotplug READD operation
powerpc/pseries: Update affinity for memory and cpus specified
from another source and grab the hotplug lock preventing the hot
add from occurring. To prevent this situation, this patch introduces the
notion of a hot "readd" action for memory which atomizes a hot remove and
a hot add into a single, serialized operation on the hotplug queue.
Signed-of
operation on the hotplug queue for any phandle included in the PRRN event
that is determined to be an LMB.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index a26a020..8836130 100644
--- a/arch/powerpc/kernel/rtasd.c
longer use the return code from the hotplug event, remove the
wait_for_completion infrastructure.
Changes from v2:
-Check if a node exists before allocating memory and call of_node_put
if the call to of_find_node_by_phandle returns successfully.
John Allen (3):
powerpc/pseries: Make the acqui
from another source and grab the hotplug lock preventing the hot
add from occurring. To prevent this situation, this patch introduces the
notion of a hot "readd" action for memory which atomizes a hot remove and
a hot add into a single, serialized operation on the hotplug queue.
Signed-of
-by: Nathan Fontenot <nf...@linux.vnet.ibm.com>
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 76ec104..0eb4b1d 100644
--- a/arch/powerpc/platforms/pseries/hotplug-me
operation on the hotplug queue for any phandle included in the PRRN event
that is determined to be an LMB.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index a26a020..8836130 100644
--- a/arch/powerpc/kernel/rtasd.c
Check if an LMB is assigned before attempting to call dlpar_acquire_drc in
order to avoid any unnecessary rtas calls. This substantially reduces the
running time of memory hot add on lpars with large amounts of memory.
Signed-off-by: John Allen <jal...@linux.vnet.ibm.com>
---
diff --git
On 08/24/2017 05:33 AM, Michael Ellerman wrote:
> John Allen <jal...@linux.vnet.ibm.com> writes:
>
>> Check if an LMB is assigned before attempting to call dlpar_acquire_drc in
>> order to avoid any unnecessary rtas calls. This substantially reduces the
>> running t
On 08/30/2017 09:35 AM, Nathan Fontenot wrote:
> On 08/29/2017 09:35 PM, Michael Ellerman wrote:
>> John Allen <jal...@linux.vnet.ibm.com> writes:
>>
>>> Check if an LMB is assigned before attempting to call dlpar_acquire_drc in
>>> order to avoid any unn
On Wed, Jul 25, 2018 at 10:03:36PM +0200, Michal Hocko wrote:
On Wed 25-07-18 13:11:15, John Allen wrote:
[...]
Does a failure in do_migrate_range indicate that the range is unmigratable
and the loop in __offline_pages should terminate and goto failed_removal? Or
should we allow a certain
On Wed, Aug 01, 2018 at 11:16:22PM +1000, Michael Ellerman wrote:
John Allen writes:
On Mon, Jul 23, 2018 at 11:41:24PM +1000, Michael Ellerman wrote:
John Allen writes:
While handling PRRN events, the time to handle the actual hotplug events
dwarfs the time it takes to perform the device
case rtas polling gets indefinitely blocked completely.
This patch removes the blocking call to flush_work and allows the
default workqueue behavior to handle duplicate events.
Signed-off-by: John Allen
---
v3:
-Scrap the mutex as it only replicates existing workqueue behavior.
v2:
-Unlock
, not after handler is
scheduled.
-Remove call to flush_work, the previous broken method of serializing
PRRN events.
John Allen (2):
powerpc/pseries: Avoid blocking rtas polling handling multiple PRRN
events
powerpc/pseries: Wait for completion of hotplug events during PRRN
actually handle them. This patch avoids the problem by waiting for a
hotplug request to complete before queueing more hotplug events.
Signed-off-by: John Allen
---
arch/powerpc/platforms/pseries/mobility.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc
On Wed, Aug 01, 2018 at 11:02:59PM +1000, Michael Ellerman wrote:
Hi John,
I'm still not sure about this one.
John Allen writes:
On Mon, Jul 23, 2018 at 11:27:56PM +1000, Michael Ellerman wrote:
Hi John,
I'm a bit puzzled by this one.
John Allen writes:
When a PRRN event is being
actually handle them. This patch avoids the problem by waiting for a
hotplug request to complete before queueing more hotplug events.
Signed-off-by: John Allen
---
arch/powerpc/platforms/pseries/mobility.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc
case rtas polling gets indefinitely blocked completely.
This patch introduces a mutex that prevents any subsequent PRRN events from
running while there is a prrn event being handled, allowing rtas polling to
continue normally.
Signed-off-by: John Allen
---
v2:
-Unlock prrn_lock when PRRN
On Fri, Jul 13, 2018 at 09:22:23AM -0500, John Allen wrote:
When a PRRN event is being handled and another PRRN event comes in, the
second event will block rtas polling waiting on the first to complete,
preventing any further rtas events from being handled. This can be
especially problematic
to
queue a single dlpar event at any given time. Additionally, it ensures
that rtas polling continues normally when multiple PRRN events are queued
simultaneously.
John Allen (2):
pseries/prrn: Avoid blocking rtas polling handling multiple PRRN
events
pseries/prrn: Wait for completion
actually handle them. This patch avoids the problem by waiting for a
hotplug request to complete before queueing more hotplug events.
Signed-off-by: John Allen
---
arch/powerpc/platforms/pseries/mobility.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc
case rtas polling gets indefinitely blocked completely.
This patch introduces a mutex that prevents any subsequent PRRN events from
running while there is a prrn event being handled, allowing rtas polling to
continue normally.
Signed-off-by: John Allen
---
arch/powerpc/kernel/rtasd.c | 11
On Mon, Jul 23, 2018 at 11:41:24PM +1000, Michael Ellerman wrote:
John Allen writes:
While handling PRRN events, the time to handle the actual hotplug events
dwarfs the time it takes to perform the device tree updates and queue the
hotplug events. In the case that PRRN events are being queued
On Fri, Jul 13, 2018 at 03:18:01PM -0500, Michael Bringmann wrote:
migration/dlpar: This patch adds function dlpar_queue_action()
which will queued up information about a CPU/Memory 'readd'
operation according to resource type, action code, and DRC index.
At a subsequent point, the list of
Hi All,
Under heavy stress and constant memory hot add/remove, I have observed
the following loop to occasionally loop infinitely:
mm/memory_hotplug.c:__offline_pages
repeat:
/* start memory hot removal */
ret = -EINTR;
if (signal_pending(current))
goto
On Mon, Jul 23, 2018 at 11:27:56PM +1000, Michael Ellerman wrote:
Hi John,
I'm a bit puzzled by this one.
John Allen writes:
When a PRRN event is being handled and another PRRN event comes in, the
second event will block rtas polling waiting on the first to complete,
preventing any further
47 matches
Mail list logo
