All of lore.kernel.org
 help / color / mirror / Atom feed
From: qiuxishi@huawei.com (Xishi Qiu)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
Date: Fri, 2 Dec 2016 11:11:21 +0800	[thread overview]
Message-ID: <5840E659.6000104@huawei.com> (raw)
In-Reply-To: <9cfa95ca-a9e9-299d-d020-7e565562dcf5@broadcom.com>

On 2016/12/2 10:38, Scott Branden wrote:

> Hi Xishi,
> 
> Thanks for the reply - please see comments below.
> 
> On 16-12-01 05:49 PM, Xishi Qiu wrote:
>> On 2016/12/2 8:19, Scott Branden wrote:
>>
>>> This patchset is sent for comment to add memory hotplug support for ARM64
>>> based platforms.  It follows hotplug code added for other architectures
>>> in the linux kernel.
>>>
>>> I tried testing the memory hotplug feature following documentation from
>>> Documentation/memory-hotplug.txt.  I don't think it is working as expected
>>> - see below:
>>>
>>> To add memory to the system I did the following:
>>> echo 0x400000000 > /sys/devices/system/memory/probe
>>>
>>> The memory is displayed as system ram:
>>> cat /proc/iomem:
>>> 74000000-77ffffff : System RAM
>>>   74080000-748dffff : Kernel code
>>>   74950000-749d2fff : Kernel data
>>> 400000000-43fffffff : System RAM
>>>
>>> But does not seem to be added to the kernel memory.
>>> /proc/meminfo did not change.
>>>
>>> What else needs to be done so the memory is added to the kernel memory
>>> pool for normal allocation?
>>>
>>
>> Hi Scott,
>>
>> Do you mean it still don't support hod-add after apply this patchset?
> 
> After applying the patch it appears to partially support hot-add. Please let me know if you think it is working as expected?
> 
> The memory probe functions in that the memory is registered with the system and shows up in /proc/iomem.  But, the memory is not available in /proc/meminfo.  Do you think something else needs to be adjusted for ARM64 to hotadd the memory
> 
> I just found another clue:
> under /sys/devices/system/memory I only see one memory entry (before or after I try to hotadd additional memory).
> 
> /sys/devices/system/memory # ls
> auto_online_blocks  memory0            uevent
> block_size_bytes    probe
> 
> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 to 28 and recompile I get the following:
> /sys/devices/system/memory # ls
> auto_online_blocks  memory7            uevent
> block_size_bytes    probe
> 
> 
> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 to 27 and recompile I get the following:
> /sys/devices/system/memory # ls
> auto_online_blocks  memory14            uevent
> block_size_bytes    probe
> 
> If looks to me like something is not working properly in the ARM64 implementation.  I should expect to see multiple memoryX entries under /sys/devices/system/memory?
> 

Hi Scott,

1. Do you enable the following configs?
CONFIG_SPARSEMEM
MEMORY_HOTPLUG
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE

2. I find you missed create mapping in arch_add_memory(), and x86 has it.

3. We will add memblock first, so pfn_valid() maybe always return true(in the
following function), and this will lead __add_section() failed. Please check
it.

int pfn_valid(unsigned long pfn)
{
	return (pfn & PFN_MASK) == pfn && memblock_is_memory(pfn << PAGE_SHIFT);
}

add_memory
  add_memory_resource
    memblock_add_node
      arch_add_memory
        __add_pages
          __add_section
            pfn_valid

Thanks,
Xishi Qiu

> 
> 
>>
>> Thanks,
>> Xishi Qiu
>>
>>> Scott Branden (2):
>>>   arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
>>>     MEMORY_PROBE
>>>   arm64: defconfig: enable MEMORY_HOTPLUG config options
>>>
>>>  arch/arm64/Kconfig           | 10 ++++++++++
>>>  arch/arm64/configs/defconfig |  3 +++
>>>  arch/arm64/mm/init.c         | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 55 insertions(+)
>>>
>>
>>
>>
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Scott Branden <scott.branden@broadcom.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>, <bielski@fastmail.net>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
Date: Fri, 2 Dec 2016 11:11:21 +0800	[thread overview]
Message-ID: <5840E659.6000104@huawei.com> (raw)
In-Reply-To: <9cfa95ca-a9e9-299d-d020-7e565562dcf5@broadcom.com>

On 2016/12/2 10:38, Scott Branden wrote:

> Hi Xishi,
> 
> Thanks for the reply - please see comments below.
> 
> On 16-12-01 05:49 PM, Xishi Qiu wrote:
>> On 2016/12/2 8:19, Scott Branden wrote:
>>
>>> This patchset is sent for comment to add memory hotplug support for ARM64
>>> based platforms.  It follows hotplug code added for other architectures
>>> in the linux kernel.
>>>
>>> I tried testing the memory hotplug feature following documentation from
>>> Documentation/memory-hotplug.txt.  I don't think it is working as expected
>>> - see below:
>>>
>>> To add memory to the system I did the following:
>>> echo 0x400000000 > /sys/devices/system/memory/probe
>>>
>>> The memory is displayed as system ram:
>>> cat /proc/iomem:
>>> 74000000-77ffffff : System RAM
>>>   74080000-748dffff : Kernel code
>>>   74950000-749d2fff : Kernel data
>>> 400000000-43fffffff : System RAM
>>>
>>> But does not seem to be added to the kernel memory.
>>> /proc/meminfo did not change.
>>>
>>> What else needs to be done so the memory is added to the kernel memory
>>> pool for normal allocation?
>>>
>>
>> Hi Scott,
>>
>> Do you mean it still don't support hod-add after apply this patchset?
> 
> After applying the patch it appears to partially support hot-add. Please let me know if you think it is working as expected?
> 
> The memory probe functions in that the memory is registered with the system and shows up in /proc/iomem.  But, the memory is not available in /proc/meminfo.  Do you think something else needs to be adjusted for ARM64 to hotadd the memory
> 
> I just found another clue:
> under /sys/devices/system/memory I only see one memory entry (before or after I try to hotadd additional memory).
> 
> /sys/devices/system/memory # ls
> auto_online_blocks  memory0            uevent
> block_size_bytes    probe
> 
> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 to 28 and recompile I get the following:
> /sys/devices/system/memory # ls
> auto_online_blocks  memory7            uevent
> block_size_bytes    probe
> 
> 
> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 to 27 and recompile I get the following:
> /sys/devices/system/memory # ls
> auto_online_blocks  memory14            uevent
> block_size_bytes    probe
> 
> If looks to me like something is not working properly in the ARM64 implementation.  I should expect to see multiple memoryX entries under /sys/devices/system/memory?
> 

Hi Scott,

1. Do you enable the following configs?
CONFIG_SPARSEMEM
MEMORY_HOTPLUG
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE

2. I find you missed create mapping in arch_add_memory(), and x86 has it.

3. We will add memblock first, so pfn_valid() maybe always return true(in the
following function), and this will lead __add_section() failed. Please check
it.

int pfn_valid(unsigned long pfn)
{
	return (pfn & PFN_MASK) == pfn && memblock_is_memory(pfn << PAGE_SHIFT);
}

add_memory
  add_memory_resource
    memblock_add_node
      arch_add_memory
        __add_pages
          __add_section
            pfn_valid

Thanks,
Xishi Qiu

> 
> 
>>
>> Thanks,
>> Xishi Qiu
>>
>>> Scott Branden (2):
>>>   arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
>>>     MEMORY_PROBE
>>>   arm64: defconfig: enable MEMORY_HOTPLUG config options
>>>
>>>  arch/arm64/Kconfig           | 10 ++++++++++
>>>  arch/arm64/configs/defconfig |  3 +++
>>>  arch/arm64/mm/init.c         | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 55 insertions(+)
>>>
>>
>>
>>
> 
> .
> 

  reply	other threads:[~2016-12-02  3:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  0:19 [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support Scott Branden
2016-12-02  0:19 ` Scott Branden
2016-12-02  0:19 ` [RFC PATCH 1/2] arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE, MEMORY_PROBE Scott Branden
2016-12-02  0:19   ` Scott Branden
2016-12-02  0:19 ` [RFC PATCH 2/2] arm64: defconfig: enable MEMORY_HOTPLUG config options Scott Branden
2016-12-02  0:19   ` Scott Branden
2016-12-02  1:49 ` [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support Xishi Qiu
2016-12-02  1:49   ` Xishi Qiu
2016-12-02  2:38   ` Scott Branden
2016-12-02  2:38     ` Scott Branden
2016-12-02  3:11     ` Xishi Qiu [this message]
2016-12-02  3:11       ` Xishi Qiu
2016-12-07  8:43       ` Scott Branden
2016-12-07  8:43         ` Scott Branden
2016-12-07 11:21         ` Xishi Qiu
2016-12-07 11:21           ` Xishi Qiu
2016-12-02  9:13 ` Maciej Bielski
2016-12-02  9:13   ` Maciej Bielski
2016-12-02 10:49   ` Will Deacon
2016-12-02 10:49     ` Will Deacon
2016-12-02 10:55     ` Maciej Bielski
2016-12-02 10:55       ` Maciej Bielski
2016-12-02 17:40       ` Scott Branden
2016-12-02 17:40         ` Scott Branden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5840E659.6000104@huawei.com \
    --to=qiuxishi@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.