| 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: <5090EFA6.6030800@cn.fujitsu.com>
Date: Wed, 31 Oct 2012 17:30:14 +0800
From: Wen Congyang <wency@...fujitsu.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
CC: Lai Jiangshan <laijs@...fujitsu.com>, Mel Gorman <mgorman@...e.de>,
David Rientjes <rientjes@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
x86 maintainers <x86@...nel.org>,
Jiang Liu <jiang.liu@...wei.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Yinghai Lu <yinghai@...nel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [V5 PATCH 00/26] mm, memory-hotplug: dynamic configure movable
memory and introduce movable node
At 10/30/2012 05:50 PM, Yasuaki Ishimatsu Wrote:
> HI Lai,
>
> The patch-set is huge. Therefore, we hesitate to read the patch-set.
> I think the patch-set has multiple feature developments.
> - Development of online_movable [PATCH 1 - 3]
> - Cleanup node_state_attr [PATCH 4]
> - Introduce N_MEMORY [PATCH 5 - 18]
> - Development of kernelcore_max_addr [PATCH 19 - 25]
> - Bug fix [PATCH 26]
I have splited it to 6 patchsets:
part1: patch 1-3
http://marc.info/?l=linux-kernel&m=135166176108186&w=2
part2: patch 4
http://marc.info/?l=linux-kernel&m=135166705909544&w=2
part3: patch 5-18
http://marc.info/?l=linux-kernel&m=135167050510527&w=2
part4: patch 19-20
http://marc.info/?l=linux-kernel&m=135167344211401&w=2
part5: patch 21-25
http://marc.info/?l=linux-kernel&m=135167497312063&w=2
part6: patch 26
http://marc.info/?l=linux-kernel&m=135167512612132&w=2
>
> Why don't you separate the patch-set into each feature development?
> By separating the patch-set, many people can easily participate
> in your development.
>
> Thanks,
> Yasuaki Ishimatsu
>
> 2012/10/30 0:07, Lai Jiangshan wrote:
>> Movable memory is a very important concept of memory-management,
>> we need to consolidate it and make use of it on systems.
>>
>> Movable memory is needed for
>> o anti-fragmentation(hugepage, big-order allocation...)
>> o logic hot-remove(virtualization, Memory capacity on Demand)
>> o physic hot-remove(power-saving, hardware partitioning, hardware fault management)
>>
>> All these require dynamic configuring the memory and making better utilities of memories
>> and safer. We also need physic hot-remove, so we need movable node too.
>> (Although some systems support physic-memory-migration, we don't require all
>> memory on physic-node is movable, but movable node is still needed here
>> for logic-node if we want to make physic-migration is transparent)
>>
>> We add dynamic configuration commands "online_movalbe" and "online_kernel".
>> We also add non-dynamic boot option kernelcore_max_addr.
>> We may add some more dynamic/non-dynamic configuration in future.
>>
>>
>> The patchset is based on 3.7-rc3 with these three patches already applied:
>> https://lkml.org/lkml/2012/10/24/151
>> https://lkml.org/lkml/2012/10/26/150
>>
>> You can also simply pull all the patches from:
>> git pull https://github.com/laijs/linux.git hotplug-next
>>
>>
>>
>> Issues):
>>
>> mempolicy(M_BIND) don't act well when the nodemask has movable nodes only,
>> the kernel allocation will fail and the task can't create new task or other
>> kernel objects.
>>
>> So we change the strategy/policy
>> when the bound nodemask has movable node(s) only, we only
>> apply mempolicy for userspace allocation, don't apply it
>> for kernel allocation.
>>
>> CPUSET also has the same problem, but the code spread in page_alloc.c,
>> and we doesn't fix it yet, we can/will change allocation strategy to one of
>> these 3 strategies:
>> 1) the same strategy as mempolicy
>> 2) change cpuset, make nodemask always has at least a normal node
>> 3) split nodemask: nodemask_user and nodemask_kernel
>>
>> Thoughts?
>>
>>
>>
>> Patches):
>>
>> patch1-3: add online_movable and online_kernel, bot don't result movable node
>> Patch4 cleanup for node_state_attr
>> Patch5 introduce N_MEMORY
>> Patch6-17 use N_MEMORY instead N_HIGH_MEMORY.
>> The patches are separated by subsystem,
>> Patch18 also changes the node_states initialization
>> Patch18-20 Add MOVABLE-dedicated node
>> Patch21-25 Add kernelcore_max_addr
>> patch26: mempolicy handle movable node
>>
>>
>>
>>
>> Changes):
>>
>> change V5-V4:
>> consolidate online_movable/online_kernel
>> nodemask management
>>
>> change V4-v3
>> rebase.
>> online_movable/online_kernel can create a zone from empty
>> or empyt a zone
>>
>> change V3-v2:
>> Proper nodemask management
>>
>> change V2-V1:
>>
>> The original V1 patchset of MOVABLE-dedicated node is here:
>> http://comments.gmane.org/gmane.linux.kernel.mm/78122
>>
>> The new V2 adds N_MEMORY and a notion of "MOVABLE-dedicated node".
>> And fix some related problems.
>>
>> The orignal V1 patchset of "add online_movable" is here:
>> https://lkml.org/lkml/2012/7/4/145
>>
>> The new V2 discards the MIGRATE_HOTREMOVE approach, and use a more straight
>> implementation(only 1 patch).
>>
>>
>>
>> Lai Jiangshan (22):
>> mm, memory-hotplug: dynamic configure movable memory and portion
>> memory
>> memory_hotplug: handle empty zone when online_movable/online_kernel
>> memory_hotplug: ensure every online node has NORMAL memory
>> node: cleanup node_state_attr
>> node_states: introduce N_MEMORY
>> cpuset: use N_MEMORY instead N_HIGH_MEMORY
>> procfs: use N_MEMORY instead N_HIGH_MEMORY
>> memcontrol: use N_MEMORY instead N_HIGH_MEMORY
>> oom: use N_MEMORY instead N_HIGH_MEMORY
>> mm,migrate: use N_MEMORY instead N_HIGH_MEMORY
>> mempolicy: use N_MEMORY instead N_HIGH_MEMORY
>> hugetlb: use N_MEMORY instead N_HIGH_MEMORY
>> vmstat: use N_MEMORY instead N_HIGH_MEMORY
>> kthread: use N_MEMORY instead N_HIGH_MEMORY
>> init: use N_MEMORY instead N_HIGH_MEMORY
>> vmscan: use N_MEMORY instead N_HIGH_MEMORY
>> page_alloc: use N_MEMORY instead N_HIGH_MEMORY change the node_states
>> initialization
>> hotplug: update nodemasks management
>> numa: add CONFIG_MOVABLE_NODE for movable-dedicated node
>> memory_hotplug: allow online/offline memory to result movable node
>> page_alloc: add kernelcore_max_addr
>> mempolicy: fix is_valid_nodemask()
>>
>> Yasuaki Ishimatsu (4):
>> x86: get pg_data_t's memory from other node
>> x86: use memblock_set_current_limit() to set memblock.current_limit
>> memblock: limit memory address from memblock
>> memblock: compare current_limit with end variable at
>> memblock_find_in_range_node()
>>
>> Documentation/cgroups/cpusets.txt | 2 +-
>> Documentation/kernel-parameters.txt | 9 +
>> Documentation/memory-hotplug.txt | 19 ++-
>> arch/x86/kernel/setup.c | 4 +-
>> arch/x86/mm/init_64.c | 4 +-
>> arch/x86/mm/numa.c | 8 +-
>> drivers/base/memory.c | 27 ++--
>> drivers/base/node.c | 28 ++--
>> fs/proc/kcore.c | 2 +-
>> fs/proc/task_mmu.c | 4 +-
>> include/linux/cpuset.h | 2 +-
>> include/linux/memblock.h | 1 +
>> include/linux/memory.h | 1 +
>> include/linux/memory_hotplug.h | 13 ++-
>> include/linux/nodemask.h | 5 +
>> init/main.c | 2 +-
>> kernel/cpuset.c | 32 ++--
>> kernel/kthread.c | 2 +-
>> mm/Kconfig | 8 +
>> mm/hugetlb.c | 24 ++--
>> mm/memblock.c | 10 +-
>> mm/memcontrol.c | 18 +-
>> mm/memory_hotplug.c | 283 +++++++++++++++++++++++++++++++++--
>> mm/mempolicy.c | 48 ++++---
>> mm/migrate.c | 2 +-
>> mm/oom_kill.c | 2 +-
>> mm/page_alloc.c | 76 +++++++---
>> mm/page_cgroup.c | 2 +-
>> mm/vmscan.c | 4 +-
>> mm/vmstat.c | 4 +-
>> 30 files changed, 508 insertions(+), 138 deletions(-)
>>
>
>
> --
> 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/
>
--
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