[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51F71DE2.4020102@huawei.com>
Date: Tue, 30 Jul 2013 09:58:58 +0800
From: Li Zefan <lizefan@...wei.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...e.cz>,
Linus Torvalds <torvalds@...ux-foundation.org>,
<cgroups@...r.kernel.org>, <containers@...ts.linux-foundation.org>,
<linux-kernel@...r.kernel.org>, <kent.overstreet@...il.com>,
Glauber Costa <glommer@...il.com>,
Johannes Weiner <hannes@...xchg.org>
Subject: Re: memcg creates an unkillable task in 3.2-rc2
> I am also seeing what looks like a leak somewhere in the cgroup code as
> well. After some runs of the same reproducer I get into a state where
> after everything is clean up. All of the control groups have been
> removed and the cgroup filesystem is unmounted, I can mount a cgroup
> filesystem with that same combindation of subsystems, but I can't mount
> a cgroup filesystem with any of those subsystems in any other
> combination. So I am guessing that the superblock is from the original
> mounting is still lingering for some reason.
>
If this happens again, you can check /proc/cgroups,
#subsys_name hierarchy num_cgroups enabled
cpuset 0 1 1
debug 0 1 1
cpu 0 1 1
cpuacct 0 1 1
memory 0 1 1
devices 0 1 1
freezer 0 1 1
blkio 0 1 1
If "hierachy" is not 0, then it didn't really unmounted. If "num_cgroups"
is not 1, then there're some cgroups not really destroyed though they've
been rmdired.
--
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