In the absence of hotplug we use extra memory proportional to
(possible_nodes - online_nodes) * number_of_cgroups. PPC64 has a patch
to disable large consumption with large number of cgroups. This patch
adds hotplug support to memory cgroups and reverts the commit that
limited possible nodes to online nodes.
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <redacted>
I've tested this patches under a VM with two nodes and movable
nodes enabled. I've offlined nodes and checked that the system
and cgroups with tasks deep in the hierarchy continue to work
fine.
Balbir Singh (3):
Add basic infrastructure for memcg hotplug support
Move from all possible nodes to online nodes
powerpc: fix node_possible_map limitations
arch/powerpc/mm/numa.c | 7 ----
mm/memcontrol.c | 96 +++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 83 insertions(+), 20 deletions(-)
--
2.5.5
The lack of hotplug support makes us allocate all memory
upfront for per node data structures. With large number
of cgroups this can be an overhead. PPC64 actually limits
n_possible nodes to n_online to avoid some of this overhead.
This patch adds the basic notifiers to listen to hotplug
events and does the allocation and free of those structures
per cgroup. We walk every cgroup per event, its a trade-off
of allocating upfront vs allocating on demand and freeing
on offline.
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <redacted>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
---
mm/memcontrol.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 60 insertions(+), 8 deletions(-)
Move routines that do operations on all nodes to
just the online nodes. Most of the changes are
very obvious (like the ones related to soft limit tree
per node)
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <redacted>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
---
mm/memcontrol.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
We've fixed the memory hotplug issue with memcg, hence
this work around should not be required.
Reverts: commit 3af229f2071f
("powerpc/numa: Reset node_possible_map to only node_online_map")
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <redacted>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/numa.c | 7 -------
1 file changed, 7 deletions(-)
From: Vladimir Davydov <hidden> Date: 2016-11-16 09:01:44
Hello,
On Wed, Nov 16, 2016 at 10:44:59AM +1100, Balbir Singh wrote:
quoted hunk
The lack of hotplug support makes us allocate all memory
upfront for per node data structures. With large number
of cgroups this can be an overhead. PPC64 actually limits
n_possible nodes to n_online to avoid some of this overhead.
This patch adds the basic notifiers to listen to hotplug
events and does the allocation and free of those structures
per cgroup. We walk every cgroup per event, its a trade-off
of allocating upfront vs allocating on demand and freeing
on offline.
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <redacted>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
---
mm/memcontrol.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 60 insertions(+), 8 deletions(-)
If memcg->numainfo_events is 0, mem_cgroup_may_update_nodemask() won't
update memcg->scan_nodes. Is it OK?
+ }
What if a memory cgroup is created or destroyed while you're walking the
tree? Should we probably use get_online_mems() in mem_cgroup_alloc() to
avoid that?
Judging by __offline_pages(), the MEM_GOING_OFFLINE event is emitted
before migrating pages off the node. So, I guess freeing per-node info
here isn't quite correct, as pages still need it to be moved from the
node's LRU lists. Better move it to MEM_OFFLINE?
I guess, we should modify mem_cgroup_alloc/free() in the scope of this
patch, otherwise it doesn't make much sense IMHO. May be, it's even
worth merging patches 1 and 2 altogether.
Thanks,
Vladimir
Relax the check preventing us from hotplugging into an offline node.
This limitation was added in commit 482ec7c403d2 ("[PATCH] powerpc numa:
Support sparse online node map") to prevent adding resources to an
uninitialized node.
These days, there is no harm in doing so. The addition will actually
cause the node to be initialized and onlined; add_memory_resource()
calls hotadd_new_pgdat() (if necessary) and node_set_online().
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Nathan Fontenot <redacted>
Cc: John Allen <redacted>
Signed-off-by: Reza Arbab <redacted>
---
This applies on top of "powerpc/mm: allow memory hotplug into a
memoryless node", currently in the -mm tree:
http://lkml.kernel.org/r/1479160961-25840-2-git-send-email-arbab@linux.vnet.ibm.com
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -1091,7 +1091,7 @@ int hot_add_scn_to_nid(unsigned long scn_addr)nid=hot_add_node_scn_to_nid(scn_addr);}-if(nid<0||!node_online(nid))+if(nid<0||!node_possible(nid))nid=first_online_node;returnnid;
Hello,
On Wed, Nov 16, 2016 at 10:44:59AM +1100, Balbir Singh wrote:
quoted
The lack of hotplug support makes us allocate all memory
upfront for per node data structures. With large number
of cgroups this can be an overhead. PPC64 actually limits
n_possible nodes to n_online to avoid some of this overhead.
This patch adds the basic notifiers to listen to hotplug
events and does the allocation and free of those structures
per cgroup. We walk every cgroup per event, its a trade-off
of allocating upfront vs allocating on demand and freeing
on offline.
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <redacted>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
---
mm/memcontrol.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 60 insertions(+), 8 deletions(-)
If memcg->numainfo_events is 0, mem_cgroup_may_update_nodemask() won't
update memcg->scan_nodes. Is it OK?
quoted
+ }
What if a memory cgroup is created or destroyed while you're walking the
tree? Should we probably use get_online_mems() in mem_cgroup_alloc() to
avoid that?
The iterator internally takes rcu_read_lock() to avoid any side-effects
of cgroups added/removed. I suspect you are also suggesting using get_online_mems()
around each call to for_each_online_node
My understanding so far is
1. invalidate_reclaim_iterators should be safe (no bad side-effects)
2. mem_cgroup_free - should be safe as well
3. mem_cgroup_alloc - needs protection
4. mem_cgroup_init - needs protection
5. mem_cgroup_remove_from_tress - should be safe
Judging by __offline_pages(), the MEM_GOING_OFFLINE event is emitted
before migrating pages off the node. So, I guess freeing per-node info
here isn't quite correct, as pages still need it to be moved from the
node's LRU lists. Better move it to MEM_OFFLINE?
I guess, we should modify mem_cgroup_alloc/free() in the scope of this
patch, otherwise it doesn't make much sense IMHO. May be, it's even
worth merging patches 1 and 2 altogether.
Thanks for the review, I'll revisit the organization of the patches.
Balbir Singh
If memcg->numainfo_events is 0, mem_cgroup_may_update_nodemask() won't
update memcg->scan_nodes. Is it OK?
quoted
+ }
What if a memory cgroup is created or destroyed while you're walking the
tree? Should we probably use get_online_mems() in mem_cgroup_alloc() to
avoid that?
The iterator internally takes rcu_read_lock() to avoid any side-effects
of cgroups added/removed. I suspect you are also suggesting using get_online_mems()
around each call to for_each_online_node
My understanding so far is
1. invalidate_reclaim_iterators should be safe (no bad side-effects)
2. mem_cgroup_free - should be safe as well
3. mem_cgroup_alloc - needs protection
4. mem_cgroup_init - needs protection
5. mem_cgroup_remove_from_tress - should be safe
I'm not into the memory hotplug code, but my understanding is that if
memcg offline happens to race with node unplug, it's possible that
- mem_cgroup_free() doesn't free the node's data, because it sees the
node as already offline
- memcg hotplug code doesn't free the node's data either, because it
sees the cgroup as offline
May be, we should surround all the loops over online nodes with
get/put_online_mems() to be sure that nothing wrong can happen.
They are slow path, anyway.
Thanks,
Vladimir
From: Michal Hocko <mhocko@kernel.org> Date: 2016-11-21 14:03:44
On Wed 16-11-16 10:44:58, Balbir Singh wrote:
In the absence of hotplug we use extra memory proportional to
(possible_nodes - online_nodes) * number_of_cgroups. PPC64 has a patch
to disable large consumption with large number of cgroups. This patch
adds hotplug support to memory cgroups and reverts the commit that
limited possible nodes to online nodes.
I didn't get to read patches yet (I am currently swamped by emails after
longer vacation so bear with me) but this doesn't tell us _why_ we want
this and how much we can actaully save. In general being dynamic is more
complex and most systems tend to have possible_nodes close to
online_nodes in my experience (well at least on most reasonable
architectures). I would also appreciate some highlevel description of
the implications. E.g. how to we synchronize with the hotplug operations
when iterating node specific data structures.
Thanks!
--
Michal Hocko
SUSE Labs
In the absence of hotplug we use extra memory proportional to
(possible_nodes - online_nodes) * number_of_cgroups. PPC64 has a patch
to disable large consumption with large number of cgroups. This patch
adds hotplug support to memory cgroups and reverts the commit that
limited possible nodes to online nodes.
I didn't get to read patches yet (I am currently swamped by emails after
longer vacation so bear with me) but this doesn't tell us _why_ we want
this and how much we can actaully save.
The motivation was 3af229f2071f
(powerpc/numa: Reset node_possible_map to only node_online_map)
In general being dynamic is more
complex and most systems tend to have possible_nodes close to
online_nodes in my experience (well at least on most reasonable
architectures). I would also appreciate some highlevel description of
the implications. E.g. how to we synchronize with the hotplug operations
when iterating node specific data structures.
I agree dynamic is more complex, but I think we'll begin to see a lot
of more of it. The rules are not hard IMHO. From an implication perspective
it means that we need to get/put_online_mem_nodes in certain paths - specifically
mem_cgroup_alloc/free and mem_cgroup_init from what I can see so far
Thanks for the review!
Balbir Singh
The iterator internally takes rcu_read_lock() to avoid any side-effects
of cgroups added/removed. I suspect you are also suggesting using get_online_mems()
around each call to for_each_online_node
My understanding so far is
1. invalidate_reclaim_iterators should be safe (no bad side-effects)
2. mem_cgroup_free - should be safe as well
3. mem_cgroup_alloc - needs protection
4. mem_cgroup_init - needs protection
5. mem_cgroup_remove_from_tress - should be safe
I'm not into the memory hotplug code, but my understanding is that if
memcg offline happens to race with node unplug, it's possible that
- mem_cgroup_free() doesn't free the node's data, because it sees the
node as already offline
- memcg hotplug code doesn't free the node's data either, because it
sees the cgroup as offline
May be, we should surround all the loops over online nodes with
get/put_online_mems() to be sure that nothing wrong can happen.
They are slow path, anyway.
From: Michael Ellerman <hidden> Date: 2017-02-01 01:05:36
On Wed, 2016-11-16 at 16:45:03 UTC, Reza Arbab wrote:
Relax the check preventing us from hotplugging into an offline node.
This limitation was added in commit 482ec7c403d2 ("[PATCH] powerpc numa:
Support sparse online node map") to prevent adding resources to an
uninitialized node.
These days, there is no harm in doing so. The addition will actually
cause the node to be initialized and onlined; add_memory_resource()
calls hotadd_new_pgdat() (if necessary) and node_set_online().
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Nathan Fontenot <redacted>
Cc: John Allen <redacted>
Signed-off-by: Reza Arbab <redacted>