linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: nishimura@mxp.nes.nec.co.jp,
	Daisuke Nishimura <d-nishimura@mtf.biglobe.ne.jp>,
	linux-mm <linux-mm@kvack.org>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH] fix unused/stale swap cache handling on memcg  v3
Date: Tue, 21 Apr 2009 11:35:25 +0900	[thread overview]
Message-ID: <20090421113525.29332f3d.nishimura@mxp.nes.nec.co.jp> (raw)
In-Reply-To: <20090417171343.e848481f.kamezawa.hiroyu@jp.fujitsu.com>

Sorry for late reply.

On Fri, 17 Apr 2009 17:13:43 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Fri, 17 Apr 2009 17:12:01 +0900
> Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote:
> 
> > On Fri, 17 Apr 2009 16:58:06 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > On Fri, 17 Apr 2009 16:50:36 +0900
> > > Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote:
> > > 
> > > > On Fri, 17 Apr 2009 15:54:11 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > > > On Fri, 17 Apr 2009 15:34:55 +0900
> > > > > Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote:
> > > > > > I made a patch for reclaiming SwapCache from orphan LRU based on your patch,
> > > > > > and have been testing it these days.
> > > > > > 
> > > > > Good trial! 
> > > > > Honestly, I've written a patch to fix this problem in these days but seems to
> > > > > be over-kill ;)
> > > > > 
> > > > > 
> > > > > > Major changes from your version:
> > > > > > - count the number of orphan pages per zone and make the threshold per zone(4MB).
> > > > > > - As for type 2 of orphan SwapCache, they are usually set dirty by add_to_swap.
> > > > > >   But try_to_drop_swapcache(__remove_mapping) can't free dirty pages,
> > > > > >   so add a check and try_to_free_swap to the end of shrink_page_list.
> > > > > > 
> > > > > > It seems work fine, no "pseud leak" of SwapCache can be seen.
> > > > > > 
> > > > > > What do you think ?
> > > > > > If it's all right, I'll merge this with the orphan list framework patch
> > > > > > and send it to Andrew with other fixes of memcg that I have.
> > > > > > 
> > > > > I'm sorry but my answer is "please wait". The reason is..
> > > > > 
> > > > > 1. When global LRU works, the pages will be reclaimed.
> > > > > 2. Global LRU will work finally.
> > > > > 3. While testing, "stale" swap cache cannot be big amount.
> > > > > 
> > > > Hmm, I can't understand 2.
> > > > 
> > > > If (memsize on system) >> (swapsize on system), global LRU doesn't run
> > > > and all the swap space can be used up by these SwapCache.
> > > > This means setting mem.limit can use up all the swap space on the system.
> > > > I've tested with 50MB size of swap and it can be used up in less than 24h.
> > > > I think it's not small.
> > > > 
> > > 
> > > plz add hook to shrink_zone() to fix this as you did. 
> > > orphan list is overkilling at this stage.
> > > 
> > I see.
> > 
> > I'll make a patch, test it, and repost it in next week.
> > It can prevent at least type-2 of orphan SwapCache.
> > 
> BTW, type-1 still exits ?
> 
Ah, I meant adding to shrink_page_list():

@@ -785,6 +786,23 @@ activate_locked:
                SetPageActive(page);
                pgactivate++;
 keep_locked:
+               if (!scanning_global_lru(sc) && PageSwapCache(page)) {
+                       struct page_cgroup *pc;
+
+                       pc = lookup_page_cgroup(page);
+                       /*
+                        * Used bit of swapcache is solid under page lock.
+                        */
+                       if (unlikely(!PageCgroupUsed(pc)))
+                               /*
+                                * This can happen if the page is free'ed by
+                                * the owner process before it is added to
+                                * swapcache.
+                                * These swapcache cannot be managed by memcg
+                                * well, so free it here.
+                                */
+                               try_to_free_swap(page);
+               }
                unlock_page(page);
 keep:
                list_add(&page->lru, &ret_pages);

This cannot prevent type-1 orphan SwapCache(caused by the race
between exit() and swap-in readahead).
Type-1 can pressure the memsw usage(trigger OOM if memsw.limit is set, as a result)
and make struct mem_cgroup unfreeable even after rmdir(because it holds refcount
to mem_cgroup).

Do you have any ideas to solve orphan SwapCache problem by adding some hooks to shrink_zone() ?
(scan some pages from global LRU and check whether it's orphan SwapCache or not by
adding some code like above ?)

And, what do you think about adding above code to shrink_page_list() ?
I think it might be unnecessary if we can solve the problem in another way, though.


Thanks,
Daisuke Nishimura.

> > I'll revisit orphan list if needed in future.
> > 
> Thank you!.
> 
> Regards,
> -Kame
> 
> > 
> > Thanks,
> > Daisuke Nishimura.
> > 
> 

--
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-04-21  2:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17  4:57 [RFC] memcg: handle swapcache leak Daisuke Nishimura
2009-03-17  5:39 ` KAMEZAWA Hiroyuki
2009-03-17  6:11   ` Daisuke Nishimura
2009-03-17  7:29     ` KAMEZAWA Hiroyuki
2009-03-17  9:38       ` KAMEZAWA Hiroyuki
2009-03-18  1:17         ` Daisuke Nishimura
2009-03-18  1:34           ` KAMEZAWA Hiroyuki
2009-03-18  3:51             ` Daisuke Nishimura
2009-03-18  4:05               ` KAMEZAWA Hiroyuki
2009-03-18  8:57               ` [PATCH] fix unused/stale swap cache handling on memcg v1 (Re: " KAMEZAWA Hiroyuki
2009-03-18 14:17                 ` Daisuke Nishimura
2009-03-18 23:45                   ` KAMEZAWA Hiroyuki
2009-03-19  2:16                     ` KAMEZAWA Hiroyuki
2009-03-19  9:06                       ` [PATCH] fix unused/stale swap cache handling on memcg v2 KAMEZAWA Hiroyuki
2009-03-19 10:01                         ` Daisuke Nishimura
2009-03-19 10:13                           ` Daisuke Nishimura
2009-03-19 10:46                             ` KAMEZAWA Hiroyuki
2009-03-19 11:36                               ` KAMEZAWA Hiroyuki
2009-03-20  7:45                                 ` [PATCH] fix unused/stale swap cache handling on memcg v3 KAMEZAWA Hiroyuki
2009-03-23  1:45                                   ` Daisuke Nishimura
2009-03-23  2:41                                     ` KAMEZAWA Hiroyuki
2009-03-23  5:04                                       ` Daisuke Nishimura
2009-03-23  5:22                                         ` KAMEZAWA Hiroyuki
2009-03-24  8:32                                           ` Daisuke Nishimura
2009-03-24 23:57                                             ` KAMEZAWA Hiroyuki
2009-04-17  6:34                                               ` Daisuke Nishimura
2009-04-17  6:54                                                 ` KAMEZAWA Hiroyuki
2009-04-17  7:50                                                   ` Daisuke Nishimura
2009-04-17  7:58                                                     ` KAMEZAWA Hiroyuki
2009-04-17  8:12                                                       ` Daisuke Nishimura
2009-04-17  8:13                                                         ` KAMEZAWA Hiroyuki
2009-04-21  2:35                                                           ` Daisuke Nishimura [this message]
2009-04-21  2:57                                                             ` KAMEZAWA Hiroyuki
2009-04-21  4:05                                                               ` Daisuke Nishimura
2009-04-17  8:11                                                     ` KAMEZAWA Hiroyuki
2009-03-18  0:08       ` [RFC] memcg: handle swapcache leak Daisuke Nishimura

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=20090421113525.29332f3d.nishimura@mxp.nes.nec.co.jp \
    --to=nishimura@mxp.nes.nec.co.jp \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=d-nishimura@mtf.biglobe.ne.jp \
    --cc=hugh@veritas.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --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