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: Wed, 7 Dec 2016 19:21:14 +0800 [thread overview]
Message-ID: <5847F0AA.5050109@huawei.com> (raw)
In-Reply-To: <0f24c35b-10d5-d857-356d-01a21be48c2c@broadcom.com>
On 2016/12/7 16:43, Scott Branden wrote:
> Hi Xishi,
>
> I followed you suggestions and found pfn_valid is always true. Answers to your questions inline.
>
> I could keep debugging this but hope Marcin sends out some code - I'm quite willing to test and help clean up the patchset.
>
> On 16-12-01 07:11 PM, Xishi Qiu wrote:
>> 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
> Yes, these configs are enabled
>>
>> 2. I find you missed create mapping in arch_add_memory(), and x86 has it.
> Could you please explain this further? The patch I submitted hass arch_add_memory identical to the ia64 implementation.
Hi Scott,
I think we should create page table first for the new hotadd memory.
e.g. create_mapping_late(start, __phys_to_virt(start), size, PAGE_KERNEL);
I don't know why ia64 don't have this step.
CC Tony
>>
>> 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.
> You are correct - pfn_valid always returns true. The function is in arch/arm64/mm/init.c and different than the one you indicated below:
>
> #ifdef CONFIG_HAVE_ARCH_PFN_VALID
> int pfn_valid(unsigned long pfn)
> {
> return memblock_is_map_memory(pfn << PAGE_SHIFT);
> }
> EXPORT_SYMBOL(pfn_valid);
> #endif
>
>>
>> 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>,
"Luck, Tony" <tony.luck@intel.com>
Subject: Re: [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
Date: Wed, 7 Dec 2016 19:21:14 +0800 [thread overview]
Message-ID: <5847F0AA.5050109@huawei.com> (raw)
In-Reply-To: <0f24c35b-10d5-d857-356d-01a21be48c2c@broadcom.com>
On 2016/12/7 16:43, Scott Branden wrote:
> Hi Xishi,
>
> I followed you suggestions and found pfn_valid is always true. Answers to your questions inline.
>
> I could keep debugging this but hope Marcin sends out some code - I'm quite willing to test and help clean up the patchset.
>
> On 16-12-01 07:11 PM, Xishi Qiu wrote:
>> 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
> Yes, these configs are enabled
>>
>> 2. I find you missed create mapping in arch_add_memory(), and x86 has it.
> Could you please explain this further? The patch I submitted hass arch_add_memory identical to the ia64 implementation.
Hi Scott,
I think we should create page table first for the new hotadd memory.
e.g. create_mapping_late(start, __phys_to_virt(start), size, PAGE_KERNEL);
I don't know why ia64 don't have this step.
CC Tony
>>
>> 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.
> You are correct - pfn_valid always returns true. The function is in arch/arm64/mm/init.c and different than the one you indicated below:
>
> #ifdef CONFIG_HAVE_ARCH_PFN_VALID
> int pfn_valid(unsigned long pfn)
> {
> return memblock_is_map_memory(pfn << PAGE_SHIFT);
> }
> EXPORT_SYMBOL(pfn_valid);
> #endif
>
>>
>> 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(+)
>>>>>
>>>>
>>>>
>>>>
>>>
>>> .
>>>
>>
>>
>>
>
> .
>
next prev parent reply other threads:[~2016-12-07 11:21 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
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 [this message]
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=5847F0AA.5050109@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.