From: David Rientjes <rientjes@google.com>
To: Ying Han <yinghan@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>, Johannes Weiner <hannes@cmpxchg.org>,
Christoph Lameter <cl@linux.com>,
Wu Fengguang <fengguang.wu@intel.com>,
Andi Kleen <ak@linux.intel.com>, Hugh Dickins <hughd@google.com>,
Rik van Riel <riel@redhat.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Tejun Heo <tj@kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH 2/5] Add per cgroup reclaim watermarks.
Date: Tue, 18 Jan 2011 12:36:02 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1101181227220.18781@chino.kir.corp.google.com> (raw)
In-Reply-To: <AANLkTimo7c3pwFoQvE140o6uFDOaRvxdq6+r3tQnfuPe@mail.gmail.com>
On Tue, 18 Jan 2011, Ying Han wrote:
> I agree that "min_free_kbytes" concept doesn't apply well since there
> is no notion of "reserved pool" in memcg. I borrowed it at the
> beginning is to add a tunable to the per-memcg watermarks besides the
> hard_limit.
You may want to add a small amount of memory that a memcg may allocate
from in oom conditions, however: memory reserves are allocated per-zone
and if the entire system is oom and that includes several dozen memcgs,
for example, they could all be contending for the same memory reserves.
It would be much easier to deplete all reserves since you would have
several tasks allowed to allocate from this pool: that's not possible
without memcg since the oom killer is serialized on zones and does not
kill a task if another oom killed task is already detected in the
tasklist.
I think it would be very trivial to DoS the entire machine in this way:
set up a thousand memcgs with tasks that have core_state, for example, and
trigger them to all allocate anonymous memory up to their hard limit so
they oom at the same time. The machine should livelock with all zones
having 0 pages free.
> I read the
> patch posted from Satoru Moriya "Tunable watermarks", and introducing
> the per-memcg-per-watermark tunable
> sounds good to me. Might consider adding it to the next post.
>
Those tunable watermarks were nacked for a reason: they are internal to
the VM and should be set to sane values by the kernel with no intevention
needed by userspace. You'd need to show why a memcg would need a user to
tune its watermarks to trigger background reclaim and why that's not
possible by the kernel and how this is a special case in comparsion to the
per-zone watermarks used by the VM.
--
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 policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-01-18 20:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 22:00 [PATCH 0/5] memcg: per cgroup background reclaim Ying Han
2011-01-13 22:00 ` [PATCH 1/5] Add kswapd descriptor Ying Han
2011-01-13 22:00 ` [PATCH 2/5] Add per cgroup reclaim watermarks Ying Han
2011-01-14 0:11 ` KAMEZAWA Hiroyuki
2011-01-18 20:02 ` Ying Han
2011-01-18 20:36 ` David Rientjes [this message]
2011-01-18 21:10 ` Ying Han
2011-01-19 0:56 ` KAMEZAWA Hiroyuki
2011-01-19 2:38 ` David Rientjes
2011-01-19 2:47 ` KAMEZAWA Hiroyuki
2011-01-19 10:03 ` David Rientjes
2011-01-19 0:44 ` KAMEZAWA Hiroyuki
2011-01-13 22:00 ` [PATCH 3/5] New APIs to adjust per cgroup wmarks Ying Han
2011-01-13 22:00 ` [PATCH 4/5] Per cgroup background reclaim Ying Han
2011-01-14 0:52 ` KAMEZAWA Hiroyuki
2011-01-19 2:12 ` Ying Han
2011-01-13 22:00 ` [PATCH 5/5] Add more per memcg stats Ying Han
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=alpine.DEB.2.00.1101181227220.18781@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=cl@linux.com \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=riel@redhat.com \
--cc=tj@kernel.org \
--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