linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Ying Han <yinghan@google.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 18:38:42 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1101181831110.25382@chino.kir.corp.google.com> (raw)
In-Reply-To: <20110119095650.02db87e0.kamezawa.hiroyu@jp.fujitsu.com>

On Wed, 19 Jan 2011, KAMEZAWA Hiroyuki wrote:

> > so something like per-memcg min_wmark which also needs to be reserved upfront?
> > 
> 
> I think the variable name 'min_free_kbytes' is the source of confusion...
> It's just a watermark to trigger background reclaim. It's not reservation.
> 

min_free_kbytes alters the min watermark of zones, meaning it can increase 
or decrease the amount of memory that is reserved for GFP_ATOMIC 
allocations, those in irq context, etc.  Since oom killed tasks don't 
allocate from any watermark, it also can increase or decrease the amount 
of memory available to oom killed tasks.  In that case, it _is_ a 
reservation of memory.

The issue is that it's done per-zone and if you're contending for those 
memory reserves that some oom killed tasks need to exit and free their 
memory, then it may deplete all memory in the DoS scenario I described.

> > KAMEZAWA gave an example on his early post, which some enterprise user
> > like to keep fixed amount of free pages
> > regardless of the hard_limit.
> > 
> > Since setting the wmarks has impact on the reclaim behavior of each
> > memcg,  adding this flexibility helps the system where it like to
> > treat memcg differently based on the priority.
> > 
> 
> Please add some tricks to throttle the usage of cpu by kswapd-for-memcg
> even when the user sets some bad value. And the total number of threads/workers
> for all memcg should be throttled, too. (I think this parameter can be 
> sysctl or root cgroup parameter.)
> 

I think that you probably want to add a min_free_kbytes for each memcg 
(and users who choose not to pre-reserve memory for things like oom killed 
tasks in that cgroup may set it to 0) and then have all other watermarks 
based off that setting just like the VM currently does whenever the global 
min_free_kbytes changes.

And I agree with your point that some cpu throttling will be needed to not 
be harmful to other cgroups whenever one memcg continuously hits its low 
watermark.  I'd suggest a global sysctl for that purpose to avoid certain 
memcg's impacting the preformance of others when under continuous reclaim 
to make sure everyone's on the same playing field.

--
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>

  reply	other threads:[~2011-01-19  2:38 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
2011-01-18 21:10         ` Ying Han
2011-01-19  0:56           ` KAMEZAWA Hiroyuki
2011-01-19  2:38             ` David Rientjes [this message]
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.1101181831110.25382@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