| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <506BB7E2.2070804@jp.fujitsu.com> Date: Wed, 3 Oct 2012 12:58:26 +0900 From: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com> To: Ni zhan Chen <nizhan.chen@...il.com> CC: Andrew Morton <akpm@...ux-foundation.org>, <x86@...nel.org>, <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>, <rientjes@...gle.com>, <liuj97@...il.com>, <len.brown@...el.com>, <cl@...ux.com>, <minchan.kim@...il.com>, <kosaki.motohiro@...fujitsu.com>, <wency@...fujitsu.com> Subject: Re: [PATCH 0/2] memory-hotplug : notification of memoty block's state 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@...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@...ck.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists