From: Ni zhan Chen <nizhan.chen@gmail.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, rientjes@google.com,
liuj97@gmail.com, len.brown@intel.com, cl@linux.com,
minchan.kim@gmail.com, kosaki.motohiro@jp.fujitsu.com,
wency@cn.fujitsu.com
Subject: Re: [PATCH 0/2] memory-hotplug : notification of memoty block's state
Date: Wed, 03 Oct 2012 10:12:44 +0800 [thread overview]
Message-ID: <506B9F1C.9050504@gmail.com> (raw)
In-Reply-To: <506B930C.2080000@jp.fujitsu.com>
On 10/03/2012 09:21 AM, Yasuaki Ishimatsu wrote:
> Hi Andrew,
>
> 2012/10/03 6:42, Andrew Morton wrote:
>> On Tue, 2 Oct 2012 17:25:06 +0900
>> Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> wrote:
>>
>>> remove_memory() offlines memory. And it is called by following two
>>> cases:
>>>
>>> 1. echo offline >/sys/devices/system/memory/memoryXX/state
>>> 2. hot remove a memory device
>>>
>>> In the 1st case, the memory block's state is changed and the
>>> notification
>>> that memory block's state changed is sent to userland after calling
>>> offline_memory(). So user can notice memory block is changed.
>>>
>>> But in the 2nd case, the memory block's state is not changed and the
>>> notification is not also sent to userspcae even if calling
>>> offline_memory().
>>> So user cannot notice memory block is changed.
>>>
>>> We should also notify to userspace at 2nd case.
>>
>> These two little patches look reasonable to me.
>>
>> There's a lot of recent activity with memory hotplug! We're in the 3.7
>> merge window now so it is not a good time to be merging new material.
>
>> Also there appear to be two teams working on it and it's unclear to me
>> how well coordinated this work is?
>
> As you know, there are two teams for developing the memory hotplug.
> - Wen's patch-set
> https://lkml.org/lkml/2012/9/5/201
>
> - Lai's patch-set
> https://lkml.org/lkml/2012/9/10/180
>
> Wen's patch-set is for removing physical memory. Now, I'm splitting the
> patch-set for reviewing more easy. If the patch-set is merged into
> linux kernel, I believe that linux on x86 can hot remove a physical
> memory device.
>
> But it is not enough since we cannot remove a memory which has kernel
> memory. If we guarantee the memory hot remove, the memory must belong
> to ZONE_MOVABLE.
>
> So Lai's patch-set tries to create a movable node that the all memory
> belongs to ZONE_MOVABLE.
>
> I think there are two chances for creating the movable node.
> - boot time
> - after hot add memory
>
> - boot time
>
> For creating a movable memory, linux has two kernel parameters
> (kernelcore and movablecore). But it is not enough, since even if we
> set the kernel paramter, the movable memory is distributed evenly in
> each node. So we introduce the kernelcore_max_addr boot parameter.
> The parameter limits the range of the memory used as a kernel memory.
>
> For example, the system has following nodes.
>
> node0 : 0x40000000 - 0x80000000
> node1 : 0x80000000 - 0xc0000000
>
> And when I want to hot remove a node1, we set
> "kernelcore_max_addr=0x80000000".
> In doing so, kernel memory is limited within 0x80000000 and node1's
> memory belongs to ZONE_MOEVALBE. As a result, we can guarantee that
> node1 is a movable node and we always hot remove node1.
>
> - after hot add memory
>
> When hot adding memory, the memory belongs to ZONE_NORMAL and is offline.
> If we online the memory, the memory may have kernel memory. In this case,
> we cannot hot remove the memory. So we introduce the online_movable
> function. If we use the function as follow, the memory belongs to
> ZONE_MOVABLE.
>
> echo online_movable > /sys/devices/system/node/nodeX/memoryX/state
>
> So when new node is hot added and I echo "online_movale" to all hot added
> memory, the node's memory belongs to ZONE_MOVABLE. As a result, we can Y
> guarantee that the node is a movable node and we always hot remove node.
Hi Yasuaki,
This time can kernel memory allocated from ZONE_MOVABLE ?
>
> # I hope to help your understanding about our works by the information.
>
> Thanks,
> Yasuaki Ishimatsu
>
>>
>> However these two patches are pretty simple and do fix a problem, so I
>> added them to the 3.7 MM queue.
>>
>
>
> --
> 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>
next prev parent reply other threads:[~2012-10-03 2:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-02 8:25 [PATCH 0/2] memory-hotplug : notification of memoty block's state Yasuaki Ishimatsu
2012-10-02 8:27 ` [Patch 1/2] memory-hotplug : Preparation to notify memory block's state at memory hot remove Yasuaki Ishimatsu
2012-10-02 8:28 ` [Patch 2/2] memory-hotplug : update memory block's state and notfy theinformation to userspace Yasuaki Ishimatsu
2012-10-02 9:42 ` [PATCH 0/2] memory-hotplug : notification of memoty block's state Ni zhan Chen
2012-10-02 10:00 ` Yasuaki Ishimatsu
2012-10-02 21:42 ` Andrew Morton
2012-10-03 1:21 ` Yasuaki Ishimatsu
2012-10-03 2:12 ` Ni zhan Chen [this message]
2012-10-03 3:58 ` Yasuaki Ishimatsu
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=506B9F1C.9050504@gmail.com \
--to=nizhan.chen@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuj97@gmail.com \
--cc=minchan.kim@gmail.com \
--cc=rientjes@google.com \
--cc=wency@cn.fujitsu.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).