From: Zhang Zhen <zhenzhang.zhang@huawei.com>
To: David Rientjes <rientjes@google.com>
Cc: gregkh@linuxfoundation.org, laijs@cn.fujitsu.com,
sjenning@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Wang Nan <wangnan0@huawei.com>
Subject: Re: Proposal to realize hot-add *several sections one time*
Date: Fri, 13 Jun 2014 15:31:43 +0800 [thread overview]
Message-ID: <539AA8DF.4060805@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1406120002410.23724@chino.kir.corp.google.com>
On 2014/6/12 15:07, David Rientjes wrote:
> On Thu, 12 Jun 2014, Zhang Zhen wrote:
>
>>>> % echo start_address_of_new_memory count_of_sections > /sys/devices/system/memory/probe
>>>>
>>>> Then, [start_address_of_new_memory, start_address_of_new_memory +
>>>> count_of_sections * memory_block_size] memory range is hot-added.
>>>>
>>>> If this proposal is reasonable, i will send a patch to realize it.
>>>>
>>>
>>> The problem is knowing how much memory is being onlined so that you can
>>> definitively determine what count_of_sections should be. The number of
>>> pages per memory section depends on PAGE_SIZE and SECTION_SIZE_BITS which
>>> differ depending on the architectures that support this interface. So if
>>> you support count_of_sections, it would return errno even though you have
>>> onlined some sections.
>>>
>> Hum, sorry.
>> My expression is not right. The count of sections one time hot-added
>> depends on sections_per_block.
>>
>
> Ok, so you know specifically what sections_per_block is for your platform
> so you know exactly how many sections need to be added.
>
>> Now we are porting the memory-hotplug to arm.
>> But we can only hot-add *fixed number of sections one time* on particular architecture.
>>
>> Whether we can add an argument on behalf of the count of the blocks to add ?
>>
>> % echo start_address_of_new_memory count_of_blocks > /sys/devices/system/memory/probe
>>
>> Then, [start_address_of_new_memory, start_address_of_new_memory + count_of_blocks * memory_block_size]
>> memory range is hot-added.
>>
>
> As I said, if the above returns errno at some point, it still can result
> in some sections being onlined. To be clear: if
> "echo 0x10000000 > /sys/devices/system/memory/probe" fails, the section
> starting at address 0x10000000 failed to be onlined for the reason
> specified by errno. If we follow your suggestion to specify how many
> sections to online, if
> "echo '0x10000000 16' > /sys/devices/system/memory/probe" fails, eight
> sections could have been successfully onlined at address 0x10000000 and
> then we encountered a failure (perhaps because the next sections were
> already onlined, we get an -EEXIST). We don't know what we successfully
> onlined.
>
> This could be mitigated, but there would have to be a convincing reason
> that this is better than using the currently functionally in a loop and
> properly handling your error codes.
Hi David,
I think you are right.
We had better to use the currently functionally in a loop if we need to add
several blocks.
In this way, we can get an errno in time if a block failed to be onlined.
Thanks for your comments. I got it.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Zhang Zhen <zhenzhang.zhang@huawei.com>
To: David Rientjes <rientjes@google.com>
Cc: <gregkh@linuxfoundation.org>, <laijs@cn.fujitsu.com>,
<sjenning@linux.vnet.ibm.com>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, Wang Nan <wangnan0@huawei.com>
Subject: Re: Proposal to realize hot-add *several sections one time*
Date: Fri, 13 Jun 2014 15:31:43 +0800 [thread overview]
Message-ID: <539AA8DF.4060805@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1406120002410.23724@chino.kir.corp.google.com>
On 2014/6/12 15:07, David Rientjes wrote:
> On Thu, 12 Jun 2014, Zhang Zhen wrote:
>
>>>> % echo start_address_of_new_memory count_of_sections > /sys/devices/system/memory/probe
>>>>
>>>> Then, [start_address_of_new_memory, start_address_of_new_memory +
>>>> count_of_sections * memory_block_size] memory range is hot-added.
>>>>
>>>> If this proposal is reasonable, i will send a patch to realize it.
>>>>
>>>
>>> The problem is knowing how much memory is being onlined so that you can
>>> definitively determine what count_of_sections should be. The number of
>>> pages per memory section depends on PAGE_SIZE and SECTION_SIZE_BITS which
>>> differ depending on the architectures that support this interface. So if
>>> you support count_of_sections, it would return errno even though you have
>>> onlined some sections.
>>>
>> Hum, sorry.
>> My expression is not right. The count of sections one time hot-added
>> depends on sections_per_block.
>>
>
> Ok, so you know specifically what sections_per_block is for your platform
> so you know exactly how many sections need to be added.
>
>> Now we are porting the memory-hotplug to arm.
>> But we can only hot-add *fixed number of sections one time* on particular architecture.
>>
>> Whether we can add an argument on behalf of the count of the blocks to add ?
>>
>> % echo start_address_of_new_memory count_of_blocks > /sys/devices/system/memory/probe
>>
>> Then, [start_address_of_new_memory, start_address_of_new_memory + count_of_blocks * memory_block_size]
>> memory range is hot-added.
>>
>
> As I said, if the above returns errno at some point, it still can result
> in some sections being onlined. To be clear: if
> "echo 0x10000000 > /sys/devices/system/memory/probe" fails, the section
> starting at address 0x10000000 failed to be onlined for the reason
> specified by errno. If we follow your suggestion to specify how many
> sections to online, if
> "echo '0x10000000 16' > /sys/devices/system/memory/probe" fails, eight
> sections could have been successfully onlined at address 0x10000000 and
> then we encountered a failure (perhaps because the next sections were
> already onlined, we get an -EEXIST). We don't know what we successfully
> onlined.
>
> This could be mitigated, but there would have to be a convincing reason
> that this is better than using the currently functionally in a loop and
> properly handling your error codes.
Hi David,
I think you are right.
We had better to use the currently functionally in a loop if we need to add
several blocks.
In this way, we can get an errno in time if a block failed to be onlined.
Thanks for your comments. I got it.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
>
next prev parent reply other threads:[~2014-06-13 7:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 9:12 Proposal to realize hot-add *several sections one time* Zhang Zhen
2014-06-11 9:12 ` Zhang Zhen
2014-06-11 22:08 ` David Rientjes
2014-06-11 22:08 ` David Rientjes
2014-06-11 22:15 ` [patch] mm, hotplug: probe interface is available on several platforms David Rientjes
2014-06-11 22:15 ` David Rientjes
2014-06-11 22:22 ` Dave Hansen
2014-06-11 22:22 ` Dave Hansen
2014-06-12 2:41 ` Proposal to realize hot-add *several sections one time* Zhang Zhen
2014-06-12 2:41 ` Zhang Zhen
2014-06-12 7:07 ` David Rientjes
2014-06-12 7:07 ` David Rientjes
2014-06-13 7:31 ` Zhang Zhen [this message]
2014-06-13 7:31 ` Zhang Zhen
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=539AA8DF.4060805@huawei.com \
--to=zhenzhang.zhang@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=sjenning@linux.vnet.ibm.com \
--cc=wangnan0@huawei.com \
/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.