Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ea280e7b authored by Tejun Heo's avatar Tejun Heo
Browse files

memcg: update memcg_has_children() to use css_next_child() 



Currently, memcg_has_children() and mem_cgroup_hierarchy_write()
directly test cgroup->children for list emptiness.  It's semantically
correct in traditional hierarchies as it actually wants to test for
any children dead or alive; however, cgroup->children is not a
published field and scheduled to go away.

This patch moves out .use_hierarchy test out of memcg_has_children()
and updates it to use css_next_child() to test whether there exists
any children.  With .use_hierarchy test moved out, it can also be used
by mem_cgroup_hierarchy_write().

A side note: As .use_hierarchy is going away, it doesn't really matter
but I'm not sure about how it's used in __memcg_activate_kmem().  The
condition tested by memcg_has_children() is mushy when seen from
userland as its result is affected by dead csses which aren't visible
from userland.  I think the rule would be a lot clearer if we have a
dedicated "freshly minted" flag which gets cleared when the first task
is migrated into it or the first child is created and then gate
activation with that.

v2: Added comment noting that testing use_hierarchy is the
    responsibility of the callers of memcg_has_children() as suggested
    by Michal Hocko.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
Acked-by: default avatarLi Zefan <lizefan@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
parent f61c42a7

mm/memcontrol.c

+21 −10
Original line number Diff line number Diff line
@@ -4834,18 +4834,28 @@ static void mem_cgroup_reparent_charges(struct mem_cgroup *memcg) 
	} while (usage > 0);

}



/*

 * Test whether @memcg has children, dead or alive.  Note that this

 * function doesn't care whether @memcg has use_hierarchy enabled and

 * returns %true if there are child csses according to the cgroup

 * hierarchy.  Testing use_hierarchy is the caller's responsiblity.

 */

static inline bool memcg_has_children(struct mem_cgroup *memcg)

{

	lockdep_assert_held(&memcg_create_mutex);

	bool ret;



	/*

	 * The lock does not prevent addition or deletion to the list

	 * of children, but it prevents a new child from being

	 * initialized based on this parent in css_online(), so it's

	 * enough to decide whether hierarchically inherited

	 * attributes can still be changed or not.

	 * The lock does not prevent addition or deletion of children, but

	 * it prevents a new child from being initialized based on this

	 * parent in css_online(), so it's enough to decide whether

	 * hierarchically inherited attributes can still be changed or not.

	 */

	return memcg->use_hierarchy &&

		!list_empty(&memcg->css.cgroup->children);

	lockdep_assert_held(&memcg_create_mutex);



	rcu_read_lock();

	ret = css_next_child(NULL, &memcg->css);

	rcu_read_unlock();

	return ret;

}



/*
@@ -4919,7 +4929,7 @@ static int mem_cgroup_hierarchy_write(struct cgroup_subsys_state *css, 
	 */

	if ((!parent_memcg || !parent_memcg->use_hierarchy) &&

				(val == 1 || val == 0)) {

		if (list_empty(&memcg->css.cgroup->children))

		if (!memcg_has_children(memcg))

			memcg->use_hierarchy = val;

		else

			retval = -EBUSY;
@@ -5036,7 +5046,8 @@ static int __memcg_activate_kmem(struct mem_cgroup *memcg, 
	 * of course permitted.

	 */

	mutex_lock(&memcg_create_mutex);

	if (cgroup_has_tasks(memcg->css.cgroup) || memcg_has_children(memcg))

	if (cgroup_has_tasks(memcg->css.cgroup) ||

	    (memcg->use_hierarchy && memcg_has_children(memcg)))

		err = -EBUSY;

	mutex_unlock(&memcg_create_mutex);

	if (err)