From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, Sudhir Kumar <skumar@linux.vnet.ibm.com>,
YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
Bharata B Rao <bharata@in.ibm.com>,
Paul Menage <menage@google.com>,
lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Pavel Emelianov <xemul@openvz.org>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH 0/4] Memory controller soft limit patches (v2)
Date: Tue, 17 Feb 2009 12:13:49 +0530 [thread overview]
Message-ID: <20090217064349.GC3513@balbir.in.ibm.com> (raw)
In-Reply-To: <20090217153658.225e1c5c.kamezawa.hiroyu@jp.fujitsu.com>
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 15:36:58]:
> On Tue, 17 Feb 2009 11:09:03 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 14:10:39]:
> >
> > > On Tue, 17 Feb 2009 10:11:10 +0530
> > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > >
> > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 13:03:52]:
> > > >
> > > > > On Tue, 17 Feb 2009 08:35:26 +0530
> > > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > > I don't want to add any new big burden to kernel hackers of memory management,
> > > > > they work hard to improve memory reclaim. This patch will change the behavior.
> > > > >
> > > >
> > > > I don't think I agree, this approach suggests that before doing global
> > > > reclaim, there are several groups that are using more than their
> > > > share of memory, so it makes sense to reclaim from them first.
> > > >
> > >
> > > >
> > > > > BTW, in typical bad case, several threads on cpus goes into memory recalim at once and
> > > > > all thread will visit this memcg's soft-limit tree at once and soft-limit will
> > > > > not work as desired anyway.
> > > > > You can't avoid this problem at alloc_page() hot-path.
> > > >
> > > > Even if all threads go into soft-reclaim at once, the tree will become
> > > > empty after a point and we will just return saying there are no more
> > > > memcg's to reclaim from (we remove the memcg from the tree when
> > > > reclaiming), then those threads will go into regular reclaim if there
> > > > is still memory pressure.
> > >
> > > Yes. the largest-excess group will be removed. So, it seems that it doesn't work
> > > as designed. rbtree is considered as just a hint ? If so, rbtree seems to be
> > > overkill.
> > >
> > > just a question:
> > > Assume memcg under hierarchy.
> > > ../group_A/ usage=1G, soft_limit=900M hierarchy=1
> > > 01/ usage=200M, soft_limit=100M
> > > 02/ usage=300M, soft_limit=200M
> > > 03/ usage=500M, soft_limit=300M <==== 200M over.
> > > 004/ usage=200M, soft_limit=100M
> > > 005/ usage=300M, soft_limit=200M
> > >
> > > At memory shortage, group 03's memory will be reclaimed
> > > - reclaim memory from 03, 03/004, 03/005
> > >
> > > When 100M of group 03' memory is reclaimed, group_A 's memory is reclaimd at the
> > > same time, implicitly. Doesn't this break your rb-tree ?
> > >
> > > I recommend you that soft-limit can be only applied to the node which is top of
> > > hierarchy.
> >
> > Yes, that can be done, but the reason for putting both was to target
> > the right memcg early.
> >
> My point is that sort by rb-tree is broken in above case.
>
OK, I'll explore, experiment and think about adding just the root
--
Balbir
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, Sudhir Kumar <skumar@linux.vnet.ibm.com>,
YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
Bharata B Rao <bharata@in.ibm.com>,
Paul Menage <menage@google.com>,
lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Pavel Emelianov <xemul@openvz.org>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH 0/4] Memory controller soft limit patches (v2)
Date: Tue, 17 Feb 2009 12:13:49 +0530 [thread overview]
Message-ID: <20090217064349.GC3513@balbir.in.ibm.com> (raw)
In-Reply-To: <20090217153658.225e1c5c.kamezawa.hiroyu@jp.fujitsu.com>
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 15:36:58]:
> On Tue, 17 Feb 2009 11:09:03 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 14:10:39]:
> >
> > > On Tue, 17 Feb 2009 10:11:10 +0530
> > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > >
> > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 13:03:52]:
> > > >
> > > > > On Tue, 17 Feb 2009 08:35:26 +0530
> > > > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > > > I don't want to add any new big burden to kernel hackers of memory management,
> > > > > they work hard to improve memory reclaim. This patch will change the behavior.
> > > > >
> > > >
> > > > I don't think I agree, this approach suggests that before doing global
> > > > reclaim, there are several groups that are using more than their
> > > > share of memory, so it makes sense to reclaim from them first.
> > > >
> > >
> > > >
> > > > > BTW, in typical bad case, several threads on cpus goes into memory recalim at once and
> > > > > all thread will visit this memcg's soft-limit tree at once and soft-limit will
> > > > > not work as desired anyway.
> > > > > You can't avoid this problem at alloc_page() hot-path.
> > > >
> > > > Even if all threads go into soft-reclaim at once, the tree will become
> > > > empty after a point and we will just return saying there are no more
> > > > memcg's to reclaim from (we remove the memcg from the tree when
> > > > reclaiming), then those threads will go into regular reclaim if there
> > > > is still memory pressure.
> > >
> > > Yes. the largest-excess group will be removed. So, it seems that it doesn't work
> > > as designed. rbtree is considered as just a hint ? If so, rbtree seems to be
> > > overkill.
> > >
> > > just a question:
> > > Assume memcg under hierarchy.
> > > ../group_A/ usage=1G, soft_limit=900M hierarchy=1
> > > 01/ usage=200M, soft_limit=100M
> > > 02/ usage=300M, soft_limit=200M
> > > 03/ usage=500M, soft_limit=300M <==== 200M over.
> > > 004/ usage=200M, soft_limit=100M
> > > 005/ usage=300M, soft_limit=200M
> > >
> > > At memory shortage, group 03's memory will be reclaimed
> > > - reclaim memory from 03, 03/004, 03/005
> > >
> > > When 100M of group 03' memory is reclaimed, group_A 's memory is reclaimd at the
> > > same time, implicitly. Doesn't this break your rb-tree ?
> > >
> > > I recommend you that soft-limit can be only applied to the node which is top of
> > > hierarchy.
> >
> > Yes, that can be done, but the reason for putting both was to target
> > the right memcg early.
> >
> My point is that sort by rb-tree is broken in above case.
>
OK, I'll explore, experiment and think about adding just the root
--
Balbir
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-02-17 6:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-16 11:08 [RFC][PATCH 0/4] Memory controller soft limit patches (v2) Balbir Singh
2009-02-16 11:08 ` Balbir Singh
2009-02-16 11:08 ` [RFC][PATCH 1/4] Memory controller soft limit documentation (v2) Balbir Singh
2009-02-16 11:08 ` Balbir Singh
2009-02-16 11:08 ` [RFC][PATCH 2/4] Memory controller soft limit interface (v2) Balbir Singh
2009-02-16 11:08 ` Balbir Singh
2009-02-16 11:09 ` [RFC][PATCH 3/4] Memory controller soft limit organize cgroups (v2) Balbir Singh
2009-02-16 11:09 ` Balbir Singh
2009-02-17 1:00 ` KOSAKI Motohiro
2009-02-17 1:00 ` KOSAKI Motohiro
2009-02-17 3:24 ` Balbir Singh
2009-02-17 3:24 ` Balbir Singh
2009-02-16 11:09 ` [RFC][PATCH 4/4] Memory controller soft limit reclaim on contention (v2) Balbir Singh
2009-02-16 11:09 ` Balbir Singh
2009-02-17 1:20 ` KOSAKI Motohiro
2009-02-17 1:20 ` KOSAKI Motohiro
2009-02-17 3:12 ` Balbir Singh
2009-02-17 3:12 ` Balbir Singh
2009-02-17 0:05 ` [RFC][PATCH 0/4] Memory controller soft limit patches (v2) KAMEZAWA Hiroyuki
2009-02-17 0:05 ` KAMEZAWA Hiroyuki
2009-02-17 3:05 ` Balbir Singh
2009-02-17 3:05 ` Balbir Singh
2009-02-17 4:03 ` KAMEZAWA Hiroyuki
2009-02-17 4:03 ` KAMEZAWA Hiroyuki
2009-02-17 4:20 ` KAMEZAWA Hiroyuki
2009-02-17 4:20 ` KAMEZAWA Hiroyuki
2009-02-17 4:42 ` Balbir Singh
2009-02-17 4:42 ` Balbir Singh
2009-02-17 4:41 ` Balbir Singh
2009-02-17 4:41 ` Balbir Singh
2009-02-17 5:10 ` KAMEZAWA Hiroyuki
2009-02-17 5:10 ` KAMEZAWA Hiroyuki
2009-02-17 5:39 ` Balbir Singh
2009-02-17 5:39 ` Balbir Singh
2009-02-17 6:36 ` KAMEZAWA Hiroyuki
2009-02-17 6:36 ` KAMEZAWA Hiroyuki
2009-02-17 6:43 ` Balbir Singh [this message]
2009-02-17 6:43 ` Balbir Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090217064349.GC3513@balbir.in.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bharata@in.ibm.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=skumar@linux.vnet.ibm.com \
--cc=xemul@openvz.org \
--cc=yamamoto@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.