From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Ying Han <yinghan@google.com>, Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hugh Dickins <hughd@google.com>,
Suleiman Souhlal <suleiman@google.com>
Subject: Re: [RFC 0/3] Implementation of cgroup isolation
Date: Tue, 29 Mar 2011 11:29:40 +0900 [thread overview]
Message-ID: <20110329112940.fcccd175.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20110329094756.49af153d.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, 29 Mar 2011 09:47:56 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Mon, 28 Mar 2011 17:37:02 -0700
> Ying Han <yinghan@google.com> wrote:
> > The approach we are thinking to make the page->lru exclusive solve the
> > problem. and also we should be able to break the zone->lru_lock
> > sharing.
> >
> Is zone->lru_lock is a problem even with the help of pagevecs ?
>
> If LRU management guys acks you to isolate LRUs and to make kswapd etc..
> more complex, okay, we'll go that way. This will _change_ the whole
> memcg design and concepts Maybe memcg should have some kind of balloon driver to
> work happy with isolated lru.
>
> But my current standing position is "never bad effects global reclaim".
> So, I'm not very happy with the solution.
>
> If we go that way, I guess we'll think we should have pseudo nodes/zones, which
> was proposed in early days of resource controls.(not cgroup).
>
BTW, against isolation, I have one thought.
Now, soft_limit_reclaim is not called in direct-reclaim path just because we thought
kswapd works enough well. If necessary, I think we can put soft-reclaim call in
generic do_try_to_free_pages(order=0).
So, isolation problem can be reduced to some extent, isn't it ?
Algorithm of softlimit _should_ be updated. I guess it's not heavily tested feature.
About ROOT cgroup, I think some daemon application should put _all_ process to
some controled cgroup. So, I don't want to think about limiting on ROOT cgroup
without any justification.
I'd like you to devide 'the talk on performance' and 'the talk on feature'.
"This makes makes performance better! ...and add an feature" sounds bad to me.
Thanks,
-Kame
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-29 2:36 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 9:39 Michal Hocko
2011-03-28 9:39 ` [RFC 1/3] Add mem_cgroup->isolated and configuration knob Michal Hocko
2011-03-28 9:39 ` [RFC 2/3] Implement isolated LRU cgroups Michal Hocko
2011-03-28 9:40 ` [RFC 3/3] Do not shrink isolated groups from the global reclaim Michal Hocko
2011-03-28 11:03 ` [RFC 0/3] Implementation of cgroup isolation KAMEZAWA Hiroyuki
2011-03-28 11:44 ` Michal Hocko
2011-03-29 0:09 ` KAMEZAWA Hiroyuki
2011-03-29 7:32 ` Michal Hocko
2011-03-29 7:51 ` KAMEZAWA Hiroyuki
2011-03-29 8:59 ` Michal Hocko
2011-03-29 9:41 ` KAMEZAWA Hiroyuki
2011-03-29 11:18 ` Michal Hocko
2011-03-29 13:15 ` Zhu Yanhai
2011-03-29 13:42 ` Michal Hocko
2011-03-29 14:02 ` Zhu Yanhai
2011-03-29 14:08 ` Zhu Yanhai
2011-03-30 7:42 ` Michal Hocko
2011-03-30 5:32 ` Ying Han
2011-03-29 15:53 ` Balbir Singh
2011-03-30 8:18 ` Michal Hocko
2011-03-30 17:59 ` Ying Han
2011-03-31 9:53 ` Michal Hocko
2011-03-31 18:10 ` Ying Han
2011-04-01 14:04 ` Michal Hocko
2011-03-31 10:01 ` Balbir Singh
2011-03-28 18:01 ` Ying Han
2011-03-29 0:12 ` KAMEZAWA Hiroyuki
2011-03-29 0:37 ` Ying Han
2011-03-29 0:47 ` KAMEZAWA Hiroyuki
2011-03-29 2:29 ` KAMEZAWA Hiroyuki [this message]
2011-03-29 3:02 ` Ying Han
2011-03-29 2:46 ` Ying Han
2011-03-29 2:45 ` KAMEZAWA Hiroyuki
2011-03-29 4:03 ` Ying Han
2011-03-29 7:53 ` Michal Hocko
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=20110329112940.fcccd175.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=suleiman@google.com \
--cc=yinghan@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox