linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: 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: Fri, 17 Apr 2009 15:54:11 +0900	[thread overview]
Message-ID: <20090417155411.76901324.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20090417153455.c6fe2ba6.nishimura@mxp.nes.nec.co.jp>

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.

But, after "soft limit", the situaion will change.
1. Even when global LRU works, page selection is influenced by memcg.
2. So, when we implement soft-limit, we need to handle swap-cache.

Your patch will be necessary finally in near future. But, now, it just
adds code and cannot be very much help, I think.

So, my answer is "please wait"


> Thanks,
> Daisuke Nishimura.
> ===
> 
> Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
> ---
>  include/linux/swap.h |    6 +++
>  mm/memcontrol.c      |  119 +++++++++++++++++++++++++++++++++++++++++++++++---
>  mm/swapfile.c        |   23 ++++++++++
>  mm/vmscan.c          |   20 ++++++++
>  4 files changed, 162 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 62d8143..02baae1 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -311,6 +311,7 @@ extern sector_t swapdev_block(int, pgoff_t);
>  extern struct swap_info_struct *get_swap_info_struct(unsigned);
>  extern int reuse_swap_page(struct page *);
>  extern int try_to_free_swap(struct page *);
> +extern int try_to_drop_swapcache(struct page *);
>  struct backing_dev_info;
>  
>  /* linux/mm/thrash.c */
> @@ -418,6 +419,11 @@ static inline int try_to_free_swap(struct page *page)
>  	return 0;
>  }
>  
> +static inline int try_to_drop_swapcache(struct page *page)
> +{
> +	return 0;
> +}
> +
>  static inline swp_entry_t get_swap_page(void)
>  {
>  	swp_entry_t entry;
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 259b09e..8638c7b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -384,10 +384,14 @@ static int mem_cgroup_walk_tree(struct mem_cgroup *root, void *data,
>  
>  struct orphan_list_node {
>  	struct orphan_list_zone {
> +		unsigned long count;
>  		struct list_head list;
>  	} zone[MAX_NR_ZONES];
>  };
>  struct orphan_list_node *orphan_list[MAX_NUMNODES] __read_mostly;
> +#define ORPHAN_THRESH (1024)	/* 4MB per zone */
> +static void try_scan_orphan_list(int, int);
> +static int memory_cgroup_is_used __read_mostly;
>  
>  static inline struct orphan_list_zone *orphan_lru(int nid, int zid)
>  {
> @@ -399,19 +403,29 @@ static inline struct orphan_list_zone *orphan_lru(int nid, int zid)
>  	return  &orphan_list[nid]->zone[zid];
>  }
>  
> -static inline void remove_orphan_list(struct page_cgroup *pc)
> +static inline void remove_orphan_list(struct page *page, struct page_cgroup *pc)
>  {
> +	struct orphan_list_zone *opl;
> +
>  	ClearPageCgroupOrphan(pc);

I wonder lock_page_cgroup() is necessary or not here..


> +	opl = orphan_lru(page_to_nid(page), page_zonenum(page));
>  	list_del_init(&pc->lru);
> +	opl->count--;
>  }
>  
>  static inline void add_orphan_list(struct page *page, struct page_cgroup *pc)
>  {
> +	int nid = page_to_nid(page);
> +	int zid = page_zonenum(page);
>  	struct orphan_list_zone *opl;
>  
>  	SetPageCgroupOrphan(pc);

here too.

I'm sorry plz give me time. I'd like to new version of post soft-limit patches
in the next week. I'm sorry for delayed my works.

Thanks,
-Kame

--
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-17  6:54 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 [this message]
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
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=20090417155411.76901324.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=d-nishimura@mtf.biglobe.ne.jp \
    --cc=hugh@veritas.com \
    --cc=linux-mm@kvack.org \
    --cc=nishimura@mxp.nes.nec.co.jp \
    /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