All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"hugh@veritas.com" <hugh@veritas.com>
Subject: Re: [PATCH] memcg: fix stale swap cache leak v5
Date: Thu, 30 Apr 2009 23:42:46 +0530	[thread overview]
Message-ID: <20090430181246.GM4430@balbir.in.ibm.com> (raw)
In-Reply-To: <20090430184738.752858ea.kamezawa.hiroyu@jp.fujitsu.com>

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-04-30 18:47:38]:

> On Thu, 30 Apr 2009 15:12:52 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-04-30 18:04:26]:
> > 
> > > On Thu, 30 Apr 2009 16:35:39 +0900
> > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > 
> > > > On Thu, 30 Apr 2009 16:16:27 +0900
> > > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > > 
> > > > > This is v5 but all codes are rewritten.
> > > > > 
> > > > > After this patch, when memcg is used,
> > > > >  1. page's swapcount is checked after I/O (without locks). If the page is
> > > > >     stale swap cache, freeing routine will be scheduled.
> > > > >  2. vmscan.c calls try_to_free_swap() when __remove_mapping() fails.
> > > > > 
> > > > > Works well for me. no extra resources and no races.
> > > > > 
> > > > > Because my office will be closed until May/7, I'll not be able to make a
> > > > > response. Posting this for showing what I think of now.
> > > > > 
> > > > I found a hole immediately after posted this...sorry. plz ignore this patch/
> > > > see you again in the next month.
> > > > 
> > > I'm now wondering to disable "swapin readahed" completely when memcg is used...
> > > Then, half of the problems will go away immediately.
> > > And it's not so bad to try to free swapcache if swap writeback ends. Then, another
> > > half will go away...
> > >
> > 
> > Could you clarify? Will memcg not account for swapin readahead pages?
> >  
> swapin-readahead pages are _not_ accounted now. (And I think _never_)
> But has race and leak swp_entry account until global LRU runs.
> 
> "Don't do swapin-readahead, at all" will remove following race completely.
> ==
>          CPU0                  CPU1
>  free_swap_and_cache()
>                         read_swapcache_async()
> ==
> swp_entry to be freed will not be read-in.
> 
> I think there will no performance regression in _usual_ case even if no readahead.
> But has no number yet.
>

Kamezawa, Daisuke,

Can't we just correct the accounting and leave the page on the global
LRU?

Daisuke in the race conditions mentioned is (2) significant? Since the
accounting is already fixed during mem_cgroup_uncharge_page()?

 

-- 
	Balbir

WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"hugh@veritas.com" <hugh@veritas.com>
Subject: Re: [PATCH] memcg: fix stale swap cache leak v5
Date: Thu, 30 Apr 2009 23:42:46 +0530	[thread overview]
Message-ID: <20090430181246.GM4430@balbir.in.ibm.com> (raw)
In-Reply-To: <20090430184738.752858ea.kamezawa.hiroyu@jp.fujitsu.com>

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-04-30 18:47:38]:

> On Thu, 30 Apr 2009 15:12:52 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-04-30 18:04:26]:
> > 
> > > On Thu, 30 Apr 2009 16:35:39 +0900
> > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > 
> > > > On Thu, 30 Apr 2009 16:16:27 +0900
> > > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > > 
> > > > > This is v5 but all codes are rewritten.
> > > > > 
> > > > > After this patch, when memcg is used,
> > > > >  1. page's swapcount is checked after I/O (without locks). If the page is
> > > > >     stale swap cache, freeing routine will be scheduled.
> > > > >  2. vmscan.c calls try_to_free_swap() when __remove_mapping() fails.
> > > > > 
> > > > > Works well for me. no extra resources and no races.
> > > > > 
> > > > > Because my office will be closed until May/7, I'll not be able to make a
> > > > > response. Posting this for showing what I think of now.
> > > > > 
> > > > I found a hole immediately after posted this...sorry. plz ignore this patch/
> > > > see you again in the next month.
> > > > 
> > > I'm now wondering to disable "swapin readahed" completely when memcg is used...
> > > Then, half of the problems will go away immediately.
> > > And it's not so bad to try to free swapcache if swap writeback ends. Then, another
> > > half will go away...
> > >
> > 
> > Could you clarify? Will memcg not account for swapin readahead pages?
> >  
> swapin-readahead pages are _not_ accounted now. (And I think _never_)
> But has race and leak swp_entry account until global LRU runs.
> 
> "Don't do swapin-readahead, at all" will remove following race completely.
> ==
>          CPU0                  CPU1
>  free_swap_and_cache()
>                         read_swapcache_async()
> ==
> swp_entry to be freed will not be read-in.
> 
> I think there will no performance regression in _usual_ case even if no readahead.
> But has no number yet.
>

Kamezawa, Daisuke,

Can't we just correct the accounting and leave the page on the global
LRU?

Daisuke in the race conditions mentioned is (2) significant? Since the
accounting is already fixed during mem_cgroup_uncharge_page()?

 

-- 
	Balbir

--
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-30 18:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-30  7:16 [PATCH] memcg: fix stale swap cache leak v5 KAMEZAWA Hiroyuki
2009-04-30  7:16 ` KAMEZAWA Hiroyuki
2009-04-30  7:35 ` KAMEZAWA Hiroyuki
2009-04-30  7:35   ` KAMEZAWA Hiroyuki
2009-04-30  9:04   ` KAMEZAWA Hiroyuki
2009-04-30  9:04     ` KAMEZAWA Hiroyuki
2009-04-30  9:42     ` Balbir Singh
2009-04-30  9:42       ` Balbir Singh
2009-04-30  9:47       ` KAMEZAWA Hiroyuki
2009-04-30  9:47         ` KAMEZAWA Hiroyuki
2009-04-30 18:12         ` Balbir Singh [this message]
2009-04-30 18:12           ` Balbir Singh
2009-05-01  4:33           ` Daisuke Nishimura
2009-05-01  4:33             ` Daisuke Nishimura
2009-05-01 18:32             ` Balbir Singh
2009-05-01 18:32               ` Balbir Singh
2009-05-02  2:56               ` Daisuke Nishimura
2009-05-02  2:56                 ` Daisuke Nishimura
2009-05-02  3:09                 ` Daisuke Nishimura
2009-05-02  3:09                   ` Daisuke Nishimura
2009-05-04 16:38             ` Balbir Singh
2009-05-04 16:38               ` Balbir Singh
2009-05-07  6:59               ` Daisuke Nishimura
2009-05-07  6:59                 ` 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=20090430181246.GM4430@balbir.in.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.