Re: [PATCH 0/2] memory-hotplug : notification of memoty block's state
From: Ni zhan Chen
Date: Tue Oct 02 2012 - 22:13:05 EST
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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/