Re: [PATCH 0/2] memory-hotplug : notification of memoty block's state

[Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>]

Hi Chen,

2012/10/03 11:12, Ni zhan Chen wrote:
> 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 ?

No. In this case, the memory cannot be used as kernel memory.

Thanks,
Yasuaki Ishimatsu

>
>>
>> # 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>