From: Michal Hocko <mhocko@suse.cz>
To: Glauber Costa <glommer@parallels.com>
Cc: Ying Han <yinghan@google.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kir Kolyshkin <kir@parallels.com>,
Pavel Emelianov <xemul@parallels.com>,
GregThelen <gthelen@google.com>,
"pjt@google.com" <pjt@google.com>,
Tim Hockin <thockin@google.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Paul Menage <paul@paulmenage.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFD] Isolated memory cgroups again
Date: Sat, 22 Oct 2011 11:47:24 +0200 [thread overview]
Message-ID: <20111022094723.GD5497@tiehlicka.suse.cz> (raw)
In-Reply-To: <4EA12FBA.7090700@parallels.com>
On Fri 21-10-11 12:39:22, Glauber Costa wrote:
> On 10/21/2011 03:41 AM, Ying Han wrote:
> >On Wed, Oct 19, 2011 at 6:33 PM, Michal Hocko<mhocko@suse.cz> wrote:
[...]
> >>TODO
[...]
> >>- is bool sufficient. Don't we rather want something like priority
> >> instead?
[...]
> >Hi Michal:
> >
> >I didn't read through the patch itself but only the description. If we
> >wanna protect a memcg being reclaimed from under global memory
> >pressure, I think we can approach it by making change on soft_limit
> >reclaim.
> >
> >I have a soft_limit change built on top of Johannes's patchset, which
> >does basically soft_limit aware reclaim under global memory pressure.
> >The implementation is simple, and I am looking forward to discuss more
> >with you guys in the conference.
> >
> >--Ying
> I don't think soft limits will help his case, if I know understand
> it correctly. Global reclaim can be triggered regardless of any soft
> limits we may set.
>
> Now, there are two things I still don't like about it:
> * The definition of a "main workload", "main cgroup", or anything
> like that.
This was just because I wanted to point out the particular case that I
am interested in. You can of course setup more cgroups to be isolated
and balance them by the soft limit.
> I'd prefer to rank them according to some parameter,
> something akin to swapiness. This would allow for other people to
> use it in a different way, while still making you capable of
> reaching your goals through parameter settings (i.e. one cgroup has
> a high value of reclaim, all others, a much lower one)
Yes, this has been mentioned in the patch TODO section (above). I wanted
the first post to be as easy as possible for the discussion starter. I
guess that we really need something like priority in fact.
>
> * The fact that you seem to want to *skip* reclaim altogether for a
> cgroup. That's a dangerous condition, IMHO. What I think we should
> try to achieve, is "skip it for practical purposes on sane
> workloads".
Yes the feature might be dangerous (we provide many ways to shoot self
toes already ;)) but that is what you get if you want to guarantee
something.
But I agree, I guess we can be more clever and if it is priority based
we can map isolation priorities to the reclaim priorities somehow.
> Again, a parameter that when set to a very high mark, has the effect
> of disallowing reclaim for a cgroup under most sane circumstances.
>
> What do you think of the above, Michal ?
Yes I guess that priority based isolation is the way to go. We should,
however, start with a consensus in this regard (should we do something
like that at all?).
Thanks
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
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>
prev parent reply other threads:[~2011-10-22 9:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-20 1:33 [RFD] Isolated memory cgroups again Michal Hocko
2011-10-20 1:59 ` KAMEZAWA Hiroyuki
2011-10-20 16:30 ` Michal Hocko
2011-10-21 16:04 ` Balbir Singh
2011-10-22 9:26 ` Michal Hocko
2011-10-21 16:11 ` Balbir Singh
2011-10-20 8:55 ` Glauber Costa
2011-10-20 16:42 ` Michal Hocko
2011-10-20 23:41 ` Ying Han
2011-10-21 2:45 ` Michal Hocko
2011-10-21 3:17 ` KAMEZAWA Hiroyuki
2011-10-21 20:00 ` Ying Han
2011-10-22 9:31 ` Michal Hocko
2011-10-21 8:39 ` Glauber Costa
2011-10-21 12:16 ` Johannes Weiner
2011-10-22 9:47 ` Michal Hocko [this message]
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=20111022094723.GD5497@tiehlicka.suse.cz \
--to=mhocko@suse.cz \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=glommer@parallels.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kir@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=paul@paulmenage.org \
--cc=pjt@google.com \
--cc=thockin@google.com \
--cc=xemul@parallels.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;
as well as URLs for NNTP newsgroup(s).