linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Subject: Re: [PATCH mmotm] vmscan: fix may_swap handling for memcg
Date: Mon, 8 Jun 2009 15:39:16 +0900	[thread overview]
Message-ID: <20090608153916.3ccaeb9a.nishimura@mxp.nes.nec.co.jp> (raw)
In-Reply-To: <20090608121848.4370.A69D9226@jp.fujitsu.com>

On Mon,  8 Jun 2009 12:20:54 +0900 (JST), KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> Hi
> 
Hi, thank you for your comment.

> > From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
> > 
> > Commit 2e2e425989080cc534fc0fca154cae515f971cf5 ("vmscan,memcg: reintroduce
> > sc->may_swap) add may_swap flag and handle it at get_scan_ratio().
> > 
> > But the result of get_scan_ratio() is ignored when priority == 0, and this
> > means, when memcg hits the mem+swap limit, anon pages can be swapped
> > just in vain. Especially when memcg causes oom by mem+swap limit,
> > we can see many and many pages are swapped out.
> > 
> > Instead of not scanning anon lru completely when priority == 0, this patch adds
> > a hook to handle may_swap flag in shrink_page_list() to avoid using useless swaps,
> > and calls try_to_free_swap() if needed because it can reduce
> > both mem.usage and memsw.usage if the page(SwapCache) is unused anymore.
> > 
> > Such unused-but-managed-under-memcg SwapCache can be made in some paths,
> > for example trylock_page() failure in free_swap_cache().
> > 
> > Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
> 
> I think root cause is following branch, right?
yes.

> if so, Why can't we handle this issue on shrink_zone()?
> 
Just because priority==0 means oom is about to happen and I don't
want to see oom if possible.
So I thought it would be better to reclaim as much pages(memsw.usage) as possible
in this case.

> 
> ---------------------------------------------------------------
> static void shrink_zone(int priority, struct zone *zone,
>                                 struct scan_control *sc)
> {
>         get_scan_ratio(zone, sc, percent);
> 
>         for_each_evictable_lru(l) {
>                 int file = is_file_lru(l);
>                 unsigned long scan;
> 
>                 scan = zone_nr_pages(zone, sc, l);
>                 if (priority) {				// !!here!!
>                         scan >>= priority;
>                         scan = (scan * percent[file]) / 100;
>                 }
> 
> 
> 
> 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-06-08  5:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08  3:02 Daisuke Nishimura
2009-06-08  3:20 ` KOSAKI Motohiro
2009-06-08  6:39   ` Daisuke Nishimura [this message]
2009-06-08  6:53     ` KOSAKI Motohiro
2009-06-08  7:54       ` Daisuke Nishimura
2009-06-09  7:13         ` [PATCH mmotm] vmscan: handle may_swap more strictly (Re: [PATCH mmotm] vmscan: fix may_swap handling for memcg) Daisuke Nishimura
2009-06-09  7:20           ` KOSAKI Motohiro
2009-06-09  7:48             ` Minchan Kim
2009-06-09  7:58               ` KOSAKI Motohiro
2009-06-09  8:19                 ` Minchan Kim
2009-06-09  8:24                   ` KOSAKI Motohiro
2009-06-09  8:35                     ` Minchan Kim
2009-06-09  8:37                       ` KOSAKI Motohiro
2009-06-09  7:28           ` KAMEZAWA Hiroyuki

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=20090608153916.3ccaeb9a.nishimura@mxp.nes.nec.co.jp \
    --to=nishimura@mxp.nes.nec.co.jp \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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