linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Ying Han <yinghan@google.com>
Cc: 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:45:55 +0900	[thread overview]
Message-ID: <20110329114555.cb5d5c51.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <BANLkTikgop4m9ngX6Dd1K6Jk7jsMMU0xig@mail.gmail.com>

On Mon, 28 Mar 2011 19:46:41 -0700
Ying Han <yinghan@google.com> wrote:

> On Mon, Mar 28, 2011 at 5:47 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> >
> >> By saying that, memcg simplified the memory accounting per-cgroup but
> >> the memory isolation is broken. This is one of examples where pages
> >> are shared between global LRU and per-memcg LRU. It is easy to get
> >> cgroup-A's page evicted by adding memory pressure to cgroup-B.
> >>
> > If you overcommit....Right ?
> 
> yes, we want to support the configuration of over-committing the
> machine w/ limit_in_bytes.
> 

Then, soft_limit is a feature for fixing the problem. If you have problem
with soft_limit, let's fix it.


> >
> >
> >> 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.
> 
> I would assume the change only apply to memcg users , otherwise
> everything is leaving in the global LRU list.
> 
> This will _change_ the whole memcg design and concepts Maybe memcg
> should have some kind of balloon driver to
> > work happy with isolated lru.
> 
> We have soft_limit hierarchical reclaim for system memory pressure,
> and also we will add per-memcg background reclaim. Both of them do
> targeting reclaim on per-memcg LRUs, and where is the balloon driver
> needed?
> 

If soft_limit is _not_ enough. And I think you background reclaim should
be work with soft_limit and be triggered by global memory pressure. 

As wrote in other mail, it's not called via direct reclaim.
Maybe its the 1st point to be shooted rather than trying big change.




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>

  reply	other threads:[~2011-03-29  2:52 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
2011-03-29  3:02           ` Ying Han
2011-03-29  2:46         ` Ying Han
2011-03-29  2:45           ` KAMEZAWA Hiroyuki [this message]
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=20110329114555.cb5d5c51.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