From: Johannes Weiner <hannes@cmpxchg.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Minchan Kim <minchan.kim@gmail.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Rik van Riel <riel@redhat.com>,
Balbir Singh <balbir@in.ibm.com>
Subject: Re: [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap)
Date: Wed, 1 Apr 2009 11:49:55 +0200 [thread overview]
Message-ID: <20090401094955.GA1656@cmpxchg.org> (raw)
In-Reply-To: <20090401180445.80b11d90.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, Apr 01, 2009 at 06:04:45PM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 1 Apr 2009 06:09:51 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > On Tue, Mar 31, 2009 at 10:48:32AM +0900, KOSAKI Motohiro wrote:
> > > > > Sorry for too late response.
> > > > > I don't know memcg well.
> > > > >
> > > > > The memcg managed to use may_swap well with global page reclaim until now.
> > > > > I think that was because may_swap can represent both meaning.
> > > > > Do we need each variables really ?
> > > > >
> > > > > How about using union variable ?
> > > >
> > > > or Just removing one of them ?
> > >
> > > I hope all may_unmap user convert to using may_swap.
> > > may_swap is more efficient and cleaner meaning.
> >
> > How about making may_swap mean the following:
> >
> > @@ -642,6 +639,8 @@ static unsigned long shrink_page_list(st
> > * Try to allocate it some swap space here.
> > */
> > if (PageAnon(page) && !PageSwapCache(page)) {
> > + if (!sc->map_swap)
> > + goto keep_locked;
> > if (!(sc->gfp_mask & __GFP_IO))
> > goto keep_locked;
> > if (!add_to_swap(page))
> >
> > try_to_free_pages() always sets it.
> >
> What is the advantage than _not_ scanning ANON LRU at all ?
I thought we could collect anon pages that don't need swap io.
> > try_to_free_mem_cgroup_pages() sets it depending on whether it really
> > wants swapping, and only swapping, right? But the above would still
> > reclaim already swapped anon pages and I don't know the memory
> > controller.
> >
> memory cgroup has 2 calls to this shrink_zone.
> 1. memory usage hits the limit.
> 2. mem+swap usage hits the limit.
>
> At "2", swap-out doesn't decrease the usage of mem+swap, then set may_swap=0.
> So, we want to kick out only file caches.
> But, we can reclaim file cache and "unmap file cache and reclaim it!" is
> necessary even if may_swap=0.
Yes.
> Then, scanning only FILE LRU makes sense at may_swap=0 *if* memcg is
> the only user of may_swap=0.
>
> Let's see others.
>
> - __zone_reclaim sets may_unmap to be 0 when they don't want swap-out.
> .....can be replaced with may_swap.
>
> - shrink_all_memory sets may_swap to be 0. Is this called by hibernation ?
> If you don't want to unmap file caches while hibernation, adding may_unmap
> as *new* paramter makes sense, I think.
Yep, that was my idea too. At least for now and then reevaluate
whether it shouldn't just reclaim in lru order without this flag...
> The change you proposed is for dropping unused SwapCache pages. Right ?
> But this will be dropped by kswapd if necessary.
>
> As far as memcg concerns, scanning ANON LRU even when may_swap=0 is just
> a waste of cpu time.
Okay.
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Minchan Kim <minchan.kim@gmail.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Rik van Riel <riel@redhat.com>,
Balbir Singh <balbir@in.ibm.com>
Subject: Re: [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap)
Date: Wed, 1 Apr 2009 11:49:55 +0200 [thread overview]
Message-ID: <20090401094955.GA1656@cmpxchg.org> (raw)
In-Reply-To: <20090401180445.80b11d90.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, Apr 01, 2009 at 06:04:45PM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 1 Apr 2009 06:09:51 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > On Tue, Mar 31, 2009 at 10:48:32AM +0900, KOSAKI Motohiro wrote:
> > > > > Sorry for too late response.
> > > > > I don't know memcg well.
> > > > >
> > > > > The memcg managed to use may_swap well with global page reclaim until now.
> > > > > I think that was because may_swap can represent both meaning.
> > > > > Do we need each variables really ?
> > > > >
> > > > > How about using union variable ?
> > > >
> > > > or Just removing one of them ?
> > >
> > > I hope all may_unmap user convert to using may_swap.
> > > may_swap is more efficient and cleaner meaning.
> >
> > How about making may_swap mean the following:
> >
> > @@ -642,6 +639,8 @@ static unsigned long shrink_page_list(st
> > * Try to allocate it some swap space here.
> > */
> > if (PageAnon(page) && !PageSwapCache(page)) {
> > + if (!sc->map_swap)
> > + goto keep_locked;
> > if (!(sc->gfp_mask & __GFP_IO))
> > goto keep_locked;
> > if (!add_to_swap(page))
> >
> > try_to_free_pages() always sets it.
> >
> What is the advantage than _not_ scanning ANON LRU at all ?
I thought we could collect anon pages that don't need swap io.
> > try_to_free_mem_cgroup_pages() sets it depending on whether it really
> > wants swapping, and only swapping, right? But the above would still
> > reclaim already swapped anon pages and I don't know the memory
> > controller.
> >
> memory cgroup has 2 calls to this shrink_zone.
> 1. memory usage hits the limit.
> 2. mem+swap usage hits the limit.
>
> At "2", swap-out doesn't decrease the usage of mem+swap, then set may_swap=0.
> So, we want to kick out only file caches.
> But, we can reclaim file cache and "unmap file cache and reclaim it!" is
> necessary even if may_swap=0.
Yes.
> Then, scanning only FILE LRU makes sense at may_swap=0 *if* memcg is
> the only user of may_swap=0.
>
> Let's see others.
>
> - __zone_reclaim sets may_unmap to be 0 when they don't want swap-out.
> .....can be replaced with may_swap.
>
> - shrink_all_memory sets may_swap to be 0. Is this called by hibernation ?
> If you don't want to unmap file caches while hibernation, adding may_unmap
> as *new* paramter makes sense, I think.
Yep, that was my idea too. At least for now and then reevaluate
whether it shouldn't just reclaim in lru order without this flag...
> The change you proposed is for dropping unused SwapCache pages. Right ?
> But this will be dropped by kswapd if necessary.
>
> As far as memcg concerns, scanning ANON LRU even when may_swap=0 is just
> a waste of cpu time.
Okay.
--
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>
next prev parent reply other threads:[~2009-04-01 9:51 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-06 3:11 [PATCH 0/3] [PATCH 0/3] swsusp: shrink file cache first Johannes Weiner
2009-02-06 3:11 ` Johannes Weiner
2009-02-06 3:11 ` [PATCH 1/3] swsusp: clean up shrink_all_zones() Johannes Weiner
2009-02-06 3:11 ` Johannes Weiner
2009-02-06 3:20 ` KOSAKI Motohiro
2009-02-06 3:20 ` KOSAKI Motohiro
2009-02-06 3:11 ` [PATCH 2/3] swsusp: dont fiddle with swappiness Johannes Weiner
2009-02-06 3:11 ` Johannes Weiner
2009-02-06 3:21 ` KOSAKI Motohiro
2009-02-06 3:21 ` KOSAKI Motohiro
2009-02-06 3:11 ` [PATCH 3/3][RFC] swsusp: shrink file cache first Johannes Weiner
2009-02-06 3:11 ` Johannes Weiner
2009-02-06 3:39 ` KOSAKI Motohiro
2009-02-06 3:39 ` KOSAKI Motohiro
2009-02-06 4:49 ` Johannes Weiner
2009-02-06 4:49 ` Johannes Weiner
2009-02-06 5:59 ` KOSAKI Motohiro
2009-02-06 5:59 ` KOSAKI Motohiro
2009-02-06 12:24 ` Johannes Weiner
2009-02-06 12:24 ` Johannes Weiner
2009-02-06 13:35 ` MinChan Kim
2009-02-06 13:35 ` MinChan Kim
2009-02-06 17:15 ` MinChan Kim
2009-02-06 17:15 ` MinChan Kim
2009-02-06 23:37 ` Johannes Weiner
2009-02-06 23:37 ` Johannes Weiner
2009-02-09 19:43 ` [patch] vmscan: rename sc.may_swap to may_unmap Johannes Weiner
2009-02-09 19:43 ` Johannes Weiner
2009-02-09 23:02 ` MinChan Kim
2009-02-09 23:02 ` MinChan Kim
2009-02-10 10:00 ` KOSAKI Motohiro
2009-02-10 10:00 ` KOSAKI Motohiro
2009-03-27 6:19 ` [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap) Daisuke Nishimura
2009-03-27 6:19 ` Daisuke Nishimura
2009-03-27 6:30 ` KAMEZAWA Hiroyuki
2009-03-27 6:30 ` KAMEZAWA Hiroyuki
2009-03-29 23:45 ` KOSAKI Motohiro
2009-03-29 23:45 ` KOSAKI Motohiro
2009-03-31 0:18 ` Daisuke Nishimura
2009-03-31 0:18 ` Daisuke Nishimura
2009-03-31 1:26 ` Minchan Kim
2009-03-31 1:26 ` Minchan Kim
2009-03-31 1:42 ` KAMEZAWA Hiroyuki
2009-03-31 1:42 ` KAMEZAWA Hiroyuki
2009-03-31 1:48 ` KOSAKI Motohiro
2009-03-31 1:48 ` KOSAKI Motohiro
2009-04-01 4:09 ` Johannes Weiner
2009-04-01 4:09 ` Johannes Weiner
2009-04-01 5:08 ` Daisuke Nishimura
2009-04-01 5:08 ` Daisuke Nishimura
2009-04-01 9:04 ` KAMEZAWA Hiroyuki
2009-04-01 9:04 ` KAMEZAWA Hiroyuki
2009-04-01 9:11 ` KOSAKI Motohiro
2009-04-01 9:11 ` KOSAKI Motohiro
2009-04-01 9:49 ` Johannes Weiner [this message]
2009-04-01 9:49 ` Johannes Weiner
2009-04-01 9:55 ` KOSAKI Motohiro
2009-04-01 9:55 ` KOSAKI Motohiro
2009-04-01 16:03 ` Johannes Weiner
2009-04-01 16:03 ` Johannes Weiner
2009-03-31 1:52 ` Daisuke Nishimura
2009-03-31 1:52 ` Daisuke Nishimura
2009-02-06 21:00 ` [PATCH 3/3][RFC] swsusp: shrink file cache first Andrew Morton
2009-02-06 21:00 ` Andrew Morton
2009-02-06 23:27 ` Johannes Weiner
2009-02-06 23:27 ` Johannes Weiner
2009-02-07 17:23 ` Rafael J. Wysocki
2009-02-07 17:23 ` Rafael J. Wysocki
2009-02-08 20:56 ` Johannes Weiner
2009-02-08 20:56 ` Johannes Weiner
2009-02-07 4:41 ` Nigel Cunningham
2009-02-07 4:41 ` Nigel Cunningham
2009-02-07 16:51 ` KOSAKI Motohiro
2009-02-07 16:51 ` KOSAKI Motohiro
2009-02-07 21:20 ` Nigel Cunningham
2009-02-07 21:20 ` Nigel Cunningham
2009-02-27 13:27 ` Pavel Machek
2009-02-27 13:27 ` Pavel Machek
2009-03-01 10:37 ` KOSAKI Motohiro
2009-03-01 10:37 ` KOSAKI Motohiro
2009-02-06 8:03 ` MinChan Kim
2009-02-06 8:03 ` MinChan Kim
2009-02-06 10:06 ` MinChan Kim
2009-02-06 10:06 ` MinChan Kim
2009-02-06 11:50 ` Johannes Weiner
2009-02-06 11:50 ` Johannes Weiner
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=20090401094955.GA1656@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=balbir@in.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.com \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=riel@redhat.com \
--cc=rjw@sisk.pl \
/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.