On Fri, Dec 14, 2012 at 4:07 AM, Michal Hocko wrote:
> On Thu 13-12-12 17:14:13, Ying Han wrote:
> [...]
>> I haven't tried this patch set yet. Before I am doing that, I am
>> curious whether changing the target reclaim to be consistent with
>> global reclaim something worthy to consider based my
On Wed 12-12-12 20:24:41, Michal Hocko wrote:
> On Wed 12-12-12 10:06:52, Michal Hocko wrote:
> > On Tue 11-12-12 14:36:10, Ying Han wrote:
> [...]
> > > One exception is mem_cgroup_iter_break(), where the loop terminates
> > > with *leaked* refcnt and that is what the iter_break() needs to clean
On Thu 13-12-12 17:14:13, Ying Han wrote:
[...]
> I haven't tried this patch set yet. Before I am doing that, I am
> curious whether changing the target reclaim to be consistent with
> global reclaim something worthy to consider based my last reply:
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
>
On Thu 13-12-12 17:14:13, Ying Han wrote:
[...]
I haven't tried this patch set yet. Before I am doing that, I am
curious whether changing the target reclaim to be consistent with
global reclaim something worthy to consider based my last reply:
diff --git a/mm/vmscan.c b/mm/vmscan.c
index
On Wed 12-12-12 20:24:41, Michal Hocko wrote:
On Wed 12-12-12 10:06:52, Michal Hocko wrote:
On Tue 11-12-12 14:36:10, Ying Han wrote:
[...]
One exception is mem_cgroup_iter_break(), where the loop terminates
with *leaked* refcnt and that is what the iter_break() needs to clean
up. We
On Fri, Dec 14, 2012 at 4:07 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 13-12-12 17:14:13, Ying Han wrote:
[...]
I haven't tried this patch set yet. Before I am doing that, I am
curious whether changing the target reclaim to be consistent with
global reclaim something worthy to consider
On Wed, Dec 12, 2012 at 11:24 AM, Michal Hocko wrote:
> On Wed 12-12-12 10:06:52, Michal Hocko wrote:
>> On Tue 11-12-12 14:36:10, Ying Han wrote:
> [...]
>> > One exception is mem_cgroup_iter_break(), where the loop terminates
>> > with *leaked* refcnt and that is what the iter_break() needs to
On Wed, Dec 12, 2012 at 10:42 AM, Michal Hocko wrote:
> On Wed 12-12-12 19:34:46, Michal Hocko wrote:
>> On Wed 12-12-12 10:09:43, Ying Han wrote:
>> [...]
>> > But If i look at the callers of mem_cgroup_iter(), they all look like
>> > the following:
>> >
>> > memcg = mem_cgroup_iter(root, NULL,
On Wed, Dec 12, 2012 at 10:42 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 12-12-12 19:34:46, Michal Hocko wrote:
On Wed 12-12-12 10:09:43, Ying Han wrote:
[...]
But If i look at the callers of mem_cgroup_iter(), they all look like
the following:
memcg = mem_cgroup_iter(root, NULL,
On Wed, Dec 12, 2012 at 11:24 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 12-12-12 10:06:52, Michal Hocko wrote:
On Tue 11-12-12 14:36:10, Ying Han wrote:
[...]
One exception is mem_cgroup_iter_break(), where the loop terminates
with *leaked* refcnt and that is what the iter_break() needs
On Wed 12-12-12 10:06:52, Michal Hocko wrote:
> On Tue 11-12-12 14:36:10, Ying Han wrote:
[...]
> > One exception is mem_cgroup_iter_break(), where the loop terminates
> > with *leaked* refcnt and that is what the iter_break() needs to clean
> > up. We can not rely on the next caller of the loop
On Wed 12-12-12 19:34:46, Michal Hocko wrote:
> On Wed 12-12-12 10:09:43, Ying Han wrote:
> [...]
> > But If i look at the callers of mem_cgroup_iter(), they all look like
> > the following:
> >
> > memcg = mem_cgroup_iter(root, NULL, );
> > do {
> >
> > // do something
> >
> > memcg =
On Wed 12-12-12 10:09:43, Ying Han wrote:
[...]
> But If i look at the callers of mem_cgroup_iter(), they all look like
> the following:
>
> memcg = mem_cgroup_iter(root, NULL, );
> do {
>
> // do something
>
> memcg = mem_cgroup_iter(root, memcg, );
> } while (memcg);
>
> So we get
On Wed, Dec 12, 2012 at 1:06 AM, Michal Hocko wrote:
> On Tue 11-12-12 14:36:10, Ying Han wrote:
>> On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko wrote:
>> > On Sun 09-12-12 11:39:50, Ying Han wrote:
>> >> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
>> > [...]
>> >> >
On Wed 12-12-12 09:57:56, Ying Han wrote:
> On Wed, Dec 12, 2012 at 12:55 AM, Michal Hocko wrote:
> > On Tue 11-12-12 14:43:37, Ying Han wrote:
> >> On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko wrote:
> >> > On Tue 11-12-12 16:50:25, Michal Hocko wrote:
> >> >> On Sun 09-12-12 08:59:54, Ying
On Wed, Dec 12, 2012 at 12:55 AM, Michal Hocko wrote:
> On Tue 11-12-12 14:43:37, Ying Han wrote:
>> On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko wrote:
>> > On Tue 11-12-12 16:50:25, Michal Hocko wrote:
>> >> On Sun 09-12-12 08:59:54, Ying Han wrote:
>> >> > On Mon, Nov 26, 2012 at 10:47 AM,
On Tue 11-12-12 14:36:10, Ying Han wrote:
> On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko wrote:
> > On Sun 09-12-12 11:39:50, Ying Han wrote:
> >> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> > [...]
> >> > if (reclaim) {
> >> > - iter->position
On Tue 11-12-12 14:43:37, Ying Han wrote:
> On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko wrote:
> > On Tue 11-12-12 16:50:25, Michal Hocko wrote:
> >> On Sun 09-12-12 08:59:54, Ying Han wrote:
> >> > On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> >> [...]
> >> > > + /*
>
On Tue 11-12-12 14:43:37, Ying Han wrote:
On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+
On Tue 11-12-12 14:36:10, Ying Han wrote:
On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko mho...@suse.cz wrote:
On Sun 09-12-12 11:39:50, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
if (reclaim) {
-
On Wed, Dec 12, 2012 at 12:55 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 14:43:37, Ying Han wrote:
On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012
On Wed 12-12-12 09:57:56, Ying Han wrote:
On Wed, Dec 12, 2012 at 12:55 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 14:43:37, Ying Han wrote:
On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12
On Wed, Dec 12, 2012 at 1:06 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 14:36:10, Ying Han wrote:
On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko mho...@suse.cz wrote:
On Sun 09-12-12 11:39:50, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 12-12-12 10:09:43, Ying Han wrote:
[...]
But If i look at the callers of mem_cgroup_iter(), they all look like
the following:
memcg = mem_cgroup_iter(root, NULL, reclaim);
do {
// do something
memcg = mem_cgroup_iter(root, memcg, reclaim);
} while (memcg);
So we get
On Wed 12-12-12 19:34:46, Michal Hocko wrote:
On Wed 12-12-12 10:09:43, Ying Han wrote:
[...]
But If i look at the callers of mem_cgroup_iter(), they all look like
the following:
memcg = mem_cgroup_iter(root, NULL, reclaim);
do {
// do something
memcg =
On Wed 12-12-12 10:06:52, Michal Hocko wrote:
On Tue 11-12-12 14:36:10, Ying Han wrote:
[...]
One exception is mem_cgroup_iter_break(), where the loop terminates
with *leaked* refcnt and that is what the iter_break() needs to clean
up. We can not rely on the next caller of the loop since it
On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko wrote:
> On Tue 11-12-12 16:50:25, Michal Hocko wrote:
>> On Sun 09-12-12 08:59:54, Ying Han wrote:
>> > On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
>> [...]
>> > > + /*
>> > > +* Even if we found a group we
On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko wrote:
> On Sun 09-12-12 11:39:50, Ying Han wrote:
>> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> [...]
>> > if (reclaim) {
>> > - iter->position = id;
>> > + struct mem_cgroup
On Tue, Dec 11, 2012 at 7:50 AM, Michal Hocko wrote:
> On Sun 09-12-12 08:59:54, Ying Han wrote:
>> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> [...]
>> > + /*
>> > +* Even if we found a group we have to make sure it is
>> > alive.
>> > +
On Tue 11-12-12 17:15:59, Michal Hocko wrote:
> On Tue 11-12-12 16:50:25, Michal Hocko wrote:
> > On Sun 09-12-12 08:59:54, Ying Han wrote:
> > > On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> > [...]
> > > > + /*
> > > > +* Even if we found a group we have
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
> On Sun 09-12-12 08:59:54, Ying Han wrote:
> > On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> [...]
> > > + /*
> > > +* Even if we found a group we have to make sure it is
> > > alive.
> > > +*
On Sun 09-12-12 11:39:50, Ying Han wrote:
> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
[...]
> > if (reclaim) {
> > - iter->position = id;
> > + struct mem_cgroup *curr = memcg;
> > +
> > + if
On Sun 09-12-12 08:59:54, Ying Han wrote:
> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
[...]
> > + /*
> > +* Even if we found a group we have to make sure it is
> > alive.
> > +* css && !memcg means that the groups should be skipped and
>
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+ /*
+* Even if we found a group we have to make sure it is
alive.
+* css !memcg means that the groups should be skipped and
On Sun 09-12-12 11:39:50, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
if (reclaim) {
- iter-position = id;
+ struct mem_cgroup *curr = memcg;
+
+ if
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+ /*
+* Even if we found a group we have to make sure it is
alive.
+*
On Tue 11-12-12 17:15:59, Michal Hocko wrote:
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+ /*
+* Even if we found a group we have to
On Tue, Dec 11, 2012 at 7:50 AM, Michal Hocko mho...@suse.cz wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+ /*
+* Even if we found a group we have to make sure it is
alive.
+
On Tue, Dec 11, 2012 at 7:54 AM, Michal Hocko mho...@suse.cz wrote:
On Sun 09-12-12 11:39:50, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
if (reclaim) {
- iter-position = id;
+
On Tue, Dec 11, 2012 at 8:15 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 11-12-12 16:50:25, Michal Hocko wrote:
On Sun 09-12-12 08:59:54, Ying Han wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
[...]
+ /*
+* Even if we found a
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited
On Fri 07-12-12 11:16:23, Ying Han wrote:
> On Fri, Dec 7, 2012 at 9:27 AM, Michal Hocko wrote:
> > On Fri 07-12-12 09:12:25, Ying Han wrote:
> >> On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko wrote:
> >> > On Thu 06-12-12 19:43:52, Ying Han wrote:
> >> > [...]
> >> >> Forgot to mention, I was
On Fri, Dec 7, 2012 at 9:27 AM, Michal Hocko wrote:
> On Fri 07-12-12 09:12:25, Ying Han wrote:
>> On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko wrote:
>> > On Thu 06-12-12 19:43:52, Ying Han wrote:
>> > [...]
>> >> Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
>> >
>> >
On Fri 07-12-12 09:12:25, Ying Han wrote:
> On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko wrote:
> > On Thu 06-12-12 19:43:52, Ying Han wrote:
> > [...]
> >> Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
> >
> > Could you give a try to -mm tree as well. There are some
On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko wrote:
> On Thu 06-12-12 19:43:52, Ying Han wrote:
> [...]
>> Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
>
> Could you give a try to -mm tree as well. There are some changes for
> memcgs removal in that tree which are not
On Thu 06-12-12 19:39:41, Ying Han wrote:
[...]
> Michal,
>
> I got some trouble while running this patch with my test. The test
> creates hundreds of memcgs which each runs some workload to generate
> global pressure. At the last, it removes all the memcgs by rmdir. Then
> the cmd "ls
On Thu 06-12-12 19:43:52, Ying Han wrote:
[...]
> Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
Could you give a try to -mm tree as well. There are some changes for
memcgs removal in that tree which are not in Linus's tree.
--
Michal Hocko
SUSE Labs
--
To unsubscribe
On Thu 06-12-12 19:43:52, Ying Han wrote:
[...]
Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
Could you give a try to -mm tree as well. There are some changes for
memcgs removal in that tree which are not in Linus's tree.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from
On Thu 06-12-12 19:39:41, Ying Han wrote:
[...]
Michal,
I got some trouble while running this patch with my test. The test
creates hundreds of memcgs which each runs some workload to generate
global pressure. At the last, it removes all the memcgs by rmdir. Then
the cmd ls
On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 06-12-12 19:43:52, Ying Han wrote:
[...]
Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
Could you give a try to -mm tree as well. There are some changes for
memcgs removal in that tree which
On Fri 07-12-12 09:12:25, Ying Han wrote:
On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 06-12-12 19:43:52, Ying Han wrote:
[...]
Forgot to mention, I was testing 3.7-rc6 with the two cgroup changes :
Could you give a try to -mm tree as well. There are some
On Fri, Dec 7, 2012 at 9:27 AM, Michal Hocko mho...@suse.cz wrote:
On Fri 07-12-12 09:12:25, Ying Han wrote:
On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 06-12-12 19:43:52, Ying Han wrote:
[...]
Forgot to mention, I was testing 3.7-rc6 with the two cgroup
On Fri 07-12-12 11:16:23, Ying Han wrote:
On Fri, Dec 7, 2012 at 9:27 AM, Michal Hocko mho...@suse.cz wrote:
On Fri 07-12-12 09:12:25, Ying Han wrote:
On Fri, Dec 7, 2012 at 12:58 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 06-12-12 19:43:52, Ying Han wrote:
[...]
Forgot to
On Thu, Dec 6, 2012 at 7:39 PM, Ying Han wrote:
> On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
>> mem_cgroup_iter curently relies on css->id when walking down a group
>> hierarchy tree. This is really awkward because the tree walk depends on
>> the groups creation ordering. The only
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited
On Thu, Dec 6, 2012 at 7:39 PM, Ying Han ying...@google.com wrote:
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko mho...@suse.cz wrote:
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups
(2012/11/27 3:47), Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its children.
>
(2012/11/27 3:47), Michal Hocko wrote:
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited before its children.
Example
On 11/28/2012 01:33 PM, Michal Hocko wrote:
> On Wed 28-11-12 13:23:57, Glauber Costa wrote:
>> On 11/28/2012 01:17 PM, Michal Hocko wrote:
>>> On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
(2012/11/27 3:47), Michal Hocko wrote:
>>> [...]
> + /*
> + * Even if we
On Wed 28-11-12 13:23:57, Glauber Costa wrote:
> On 11/28/2012 01:17 PM, Michal Hocko wrote:
> > On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
> >> (2012/11/27 3:47), Michal Hocko wrote:
> > [...]
> >>> + /*
> >>> + * Even if we found a group we have to make sure it is alive.
On 11/28/2012 01:17 PM, Michal Hocko wrote:
> On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
>> (2012/11/27 3:47), Michal Hocko wrote:
> [...]
>>> + /*
>>> +* Even if we found a group we have to make sure it is alive.
>>> +* css && !memcg means that the groups
On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
> (2012/11/27 3:47), Michal Hocko wrote:
[...]
> > + /*
> > +* Even if we found a group we have to make sure it is alive.
> > +* css && !memcg means that the groups should be skipped and
> > +* we
(2012/11/27 3:47), Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its children.
>
(2012/11/27 3:47), Michal Hocko wrote:
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited before its children.
Example
On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
(2012/11/27 3:47), Michal Hocko wrote:
[...]
+ /*
+* Even if we found a group we have to make sure it is alive.
+* css !memcg means that the groups should be skipped and
+* we should continue
On 11/28/2012 01:17 PM, Michal Hocko wrote:
On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
(2012/11/27 3:47), Michal Hocko wrote:
[...]
+ /*
+* Even if we found a group we have to make sure it is alive.
+* css !memcg means that the groups should be
On Wed 28-11-12 13:23:57, Glauber Costa wrote:
On 11/28/2012 01:17 PM, Michal Hocko wrote:
On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
(2012/11/27 3:47), Michal Hocko wrote:
[...]
+ /*
+ * Even if we found a group we have to make sure it is alive.
+ *
On 11/28/2012 01:33 PM, Michal Hocko wrote:
On Wed 28-11-12 13:23:57, Glauber Costa wrote:
On 11/28/2012 01:17 PM, Michal Hocko wrote:
On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
(2012/11/27 3:47), Michal Hocko wrote:
[...]
+ /*
+ * Even if we found a group we have
mem_cgroup_iter curently relies on css->id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited before its children.
Example
1) mkdir -p a a/d a/b/c
2) mkdir -a a/b/c
mem_cgroup_iter curently relies on css-id when walking down a group
hierarchy tree. This is really awkward because the tree walk depends on
the groups creation ordering. The only guarantee is that a parent node
is visited before its children.
Example
1) mkdir -p a a/d a/b/c
2) mkdir -a a/b/c a/d
74 matches
Mail list logo
