Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754040Ab2JCBV7 (ORCPT ); Tue, 2 Oct 2012 21:21:59 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:44996 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753705Ab2JCBV5 (ORCPT ); Tue, 2 Oct 2012 21:21:57 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.7.4 Message-ID: <506B930C.2080000@jp.fujitsu.com> Date: Wed, 3 Oct 2012 10:21:16 +0900 From: Yasuaki Ishimatsu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Morton CC: , , , , , , , , , , Subject: Re: [PATCH 0/2] memory-hotplug : notification of memoty block's state References: <506AA4E2.7070302@jp.fujitsu.com> <20121002144211.b60881a8.akpm@linux-foundation.org> In-Reply-To: <20121002144211.b60881a8.akpm@linux-foundation.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3695 Lines: 100 Hi Andrew, 2012/10/03 6:42, Andrew Morton wrote: > On Tue, 2 Oct 2012 17:25:06 +0900 > Yasuaki Ishimatsu 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/