Patchwork [3/8] Add all memory via sysfs probe interface at once

login
register
mail settings
Submitter Nathan Fontenot
Date July 24, 2013, 6:37 p.m.
Message ID <51F01EFB.6070207@linux.vnet.ibm.com>
Download mbox | patch
Permalink /patch/261502/
State Superseded
Headers show

Comments

Nathan Fontenot - July 24, 2013, 6:37 p.m.
When doing memory hot add via the 'probe' interface in sysfs we do not
need to loop through and add memory one section at a time. I think this
was originally done for powerpc, but is not needed. This patch removes
the loop and just calls add_memory for all of the memory to be added.

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
 drivers/base/memory.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)
Michael Ellerman - Aug. 2, 2013, 2:32 a.m.
On Wed, Jul 24, 2013 at 01:37:47PM -0500, Nathan Fontenot wrote:
> When doing memory hot add via the 'probe' interface in sysfs we do not
> need to loop through and add memory one section at a time. I think this
> was originally done for powerpc, but is not needed. This patch removes
> the loop and just calls add_memory for all of the memory to be added.

Looks like memory hot add is supported on ia64, x86, sh, powerpc and
s390. Have you tested on any?
 
cheers
Nathan Fontenot - Aug. 2, 2013, 7:13 p.m.
On 08/01/2013 09:32 PM, Michael Ellerman wrote:
> On Wed, Jul 24, 2013 at 01:37:47PM -0500, Nathan Fontenot wrote:
>> When doing memory hot add via the 'probe' interface in sysfs we do not
>> need to loop through and add memory one section at a time. I think this
>> was originally done for powerpc, but is not needed. This patch removes
>> the loop and just calls add_memory for all of the memory to be added.
> 
> Looks like memory hot add is supported on ia64, x86, sh, powerpc and
> s390. Have you tested on any?

I have tested on powerpc. I would love to say I tested on the other
platforms... but I haven't.  I should be able to get a x86 box to test
on but the other architectures may not be possible.

-Nathan
Michael Ellerman - Aug. 5, 2013, 3:13 a.m.
On Fri, Aug 02, 2013 at 02:13:06PM -0500, Nathan Fontenot wrote:
> On 08/01/2013 09:32 PM, Michael Ellerman wrote:
> > On Wed, Jul 24, 2013 at 01:37:47PM -0500, Nathan Fontenot wrote:
> >> When doing memory hot add via the 'probe' interface in sysfs we do not
> >> need to loop through and add memory one section at a time. I think this
> >> was originally done for powerpc, but is not needed. This patch removes
> >> the loop and just calls add_memory for all of the memory to be added.
> > 
> > Looks like memory hot add is supported on ia64, x86, sh, powerpc and
> > s390. Have you tested on any?
> 
> I have tested on powerpc. I would love to say I tested on the other
> platforms... but I haven't.  I should be able to get a x86 box to test
> on but the other architectures may not be possible.

Is the rest of your series dependent on this patch? Or is it sort of
incidental?

If possible it might be worth pulling this one out and sticking it in
linux-next for a cycle to give people a chance to test it. Unless
someone who knows the code well is comfortable with it.

cheers
Nathan Fontenot - Aug. 6, 2013, 8:44 p.m.
On 08/04/2013 10:13 PM, Michael Ellerman wrote:
> On Fri, Aug 02, 2013 at 02:13:06PM -0500, Nathan Fontenot wrote:
>> On 08/01/2013 09:32 PM, Michael Ellerman wrote:
>>> On Wed, Jul 24, 2013 at 01:37:47PM -0500, Nathan Fontenot wrote:
>>>> When doing memory hot add via the 'probe' interface in sysfs we do not
>>>> need to loop through and add memory one section at a time. I think this
>>>> was originally done for powerpc, but is not needed. This patch removes
>>>> the loop and just calls add_memory for all of the memory to be added.
>>>
>>> Looks like memory hot add is supported on ia64, x86, sh, powerpc and
>>> s390. Have you tested on any?
>>
>> I have tested on powerpc. I would love to say I tested on the other
>> platforms... but I haven't.  I should be able to get a x86 box to test
>> on but the other architectures may not be possible.
> 
> Is the rest of your series dependent on this patch? Or is it sort of
> incidental?
> 
> If possible it might be worth pulling this one out and sticking it in
> linux-next for a cycle to give people a chance to test it. Unless
> someone who knows the code well is comfortable with it.
> 

I am planning on pulling the first two patches and sending them out
separate from the patch set since they are really independent of the
rest of the patch series.

The remaining code I will send out for review and inclusion in
linux-next so it can have the proper test time as you mentioned.

-Nathan
Benjamin Herrenschmidt - Aug. 9, 2013, 7:16 a.m.
On Tue, 2013-08-06 at 15:44 -0500, Nathan Fontenot wrote:
> I am planning on pulling the first two patches and sending them out
> separate from the patch set since they are really independent of the
> rest of the patch series.
> 
> The remaining code I will send out for review and inclusion in
> linux-next so it can have the proper test time as you mentioned.

Ping ? :-)

Cheers,
Ben.

Patch

Index: linux/drivers/base/memory.c
===================================================================
--- linux.orig/drivers/base/memory.c
+++ linux/drivers/base/memory.c
@@ -427,8 +427,8 @@  memory_probe_store(struct device *dev, s
 		   const char *buf, size_t count)
 {
 	u64 phys_addr;
-	int nid;
-	int i, ret;
+	int nid, ret;
+	unsigned long block_size;
 	unsigned long pages_per_block = PAGES_PER_SECTION * sections_per_block;
 
 	phys_addr = simple_strtoull(buf, NULL, 0);
@@ -436,19 +436,11 @@  memory_probe_store(struct device *dev, s
 	if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1))
 		return -EINVAL;
 
-	for (i = 0; i < sections_per_block; i++) {
-		nid = memory_add_physaddr_to_nid(phys_addr);
-		ret = add_memory(nid, phys_addr,
-				 PAGES_PER_SECTION << PAGE_SHIFT);
-		if (ret)
-			goto out;
+	block_size = get_memory_block_size();
+	nid = memory_add_physaddr_to_nid(phys_addr);
+	ret = add_memory(nid, phys_addr, block_size);
 
-		phys_addr += MIN_MEMORY_BLOCK_SIZE;
-	}
-
-	ret = count;
-out:
-	return ret;
+	return ret ? ret : count;
 }
 
 static DEVICE_ATTR(probe, S_IWUSR, NULL, memory_probe_store);