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

Yasuaki Ishimatsu
2012-10-03T01:21:16Z

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
guarantee that the node is a movable node and we always hot remove node.

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