From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Nigel Cunningham <ncunningham@crca.org.au>,
LKML <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>, "linux-mm" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCHv2 2/5] vmscan: Kill hibernation specific reclaim logic and unify it
Date: Mon, 2 Nov 2009 20:05:04 +0100 [thread overview]
Message-ID: <200911022005.04076.rjw@sisk.pl> (raw)
In-Reply-To: <20091103002520.886C.A69D9226@jp.fujitsu.com>
On Monday 02 November 2009, KOSAKI Motohiro wrote:
> Hi
>
> Thank you for the reviewing :)
>
> > > 2) shrink_all_zone() try to shrink all pages at a time. but it doesn't works
> > > fine on numa system.
> > > example)
> > > System has 4GB memory and each node have 2GB. and hibernate need 1GB.
> > >
> > > optimal)
> > > steal 500MB from each node.
> > > shrink_all_zones)
> > > steal 1GB from node-0.
> >
> > I haven't given much thought to numa awareness in hibernate code, but I
> > can say that the shrink_all_memory interface is woefully inadequate as
> > far as zone awareness goes. Since lowmem needs to be atomically restored
> > before we can restore highmem, we really need to be able to ask for a
> > particular number of pages of a particular zone type to be freed.
>
> Honestly, I am not suspend/hibernation expert. Can I ask why caller need to know
> per-zone number of freed pages information? if hibernation don't need highmem.
It does need highmem. At least the mainline version does.
> following incremental patch prevent highmem reclaim perfectly. Is it enough?
Thanks,
Rafael
> ---
> mm/vmscan.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index e6ea011..7fb3435 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2265,7 +2265,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
> {
> struct reclaim_state reclaim_state;
> struct scan_control sc = {
> - .gfp_mask = GFP_HIGHUSER_MOVABLE,
> + .gfp_mask = GFP_KERNEL,
> .may_swap = 1,
> .may_unmap = 1,
> .may_writepage = 1,
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Nigel Cunningham <ncunningham@crca.org.au>,
LKML <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>, linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCHv2 2/5] vmscan: Kill hibernation specific reclaim logic and unify it
Date: Mon, 2 Nov 2009 20:05:04 +0100 [thread overview]
Message-ID: <200911022005.04076.rjw@sisk.pl> (raw)
In-Reply-To: <20091103002520.886C.A69D9226@jp.fujitsu.com>
On Monday 02 November 2009, KOSAKI Motohiro wrote:
> Hi
>
> Thank you for the reviewing :)
>
> > > 2) shrink_all_zone() try to shrink all pages at a time. but it doesn't works
> > > fine on numa system.
> > > example)
> > > System has 4GB memory and each node have 2GB. and hibernate need 1GB.
> > >
> > > optimal)
> > > steal 500MB from each node.
> > > shrink_all_zones)
> > > steal 1GB from node-0.
> >
> > I haven't given much thought to numa awareness in hibernate code, but I
> > can say that the shrink_all_memory interface is woefully inadequate as
> > far as zone awareness goes. Since lowmem needs to be atomically restored
> > before we can restore highmem, we really need to be able to ask for a
> > particular number of pages of a particular zone type to be freed.
>
> Honestly, I am not suspend/hibernation expert. Can I ask why caller need to know
> per-zone number of freed pages information? if hibernation don't need highmem.
It does need highmem. At least the mainline version does.
> following incremental patch prevent highmem reclaim perfectly. Is it enough?
Thanks,
Rafael
> ---
> mm/vmscan.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index e6ea011..7fb3435 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2265,7 +2265,7 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
> {
> struct reclaim_state reclaim_state;
> struct scan_control sc = {
> - .gfp_mask = GFP_HIGHUSER_MOVABLE,
> + .gfp_mask = GFP_KERNEL,
> .may_swap = 1,
> .may_unmap = 1,
> .may_writepage = 1,
--
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-11-02 19:03 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-01 15:08 [PATCHv2 1/5] vmscan: separate sc.swap_cluster_max and sc.nr_max_reclaim KOSAKI Motohiro
2009-11-01 15:08 ` KOSAKI Motohiro
2009-11-01 15:09 ` [PATCHv2 2/5] vmscan: Kill hibernation specific reclaim logic and unify it KOSAKI Motohiro
2009-11-01 15:09 ` KOSAKI Motohiro
2009-11-01 15:12 ` Rik van Riel
2009-11-01 15:12 ` Rik van Riel
2009-11-01 21:38 ` Rafael J. Wysocki
2009-11-01 21:38 ` Rafael J. Wysocki
2009-11-02 15:35 ` KOSAKI Motohiro
2009-11-02 15:35 ` KOSAKI Motohiro
2009-11-02 19:03 ` Rafael J. Wysocki
2009-11-02 19:03 ` Rafael J. Wysocki
2009-11-03 14:00 ` KOSAKI Motohiro
2009-11-03 14:00 ` KOSAKI Motohiro
2009-11-03 21:51 ` Rafael J. Wysocki
2009-11-03 21:51 ` Rafael J. Wysocki
2009-11-01 22:01 ` Nigel Cunningham
2009-11-01 22:01 ` Nigel Cunningham
2009-11-02 15:35 ` KOSAKI Motohiro
2009-11-02 15:35 ` KOSAKI Motohiro
2009-11-02 19:05 ` Rafael J. Wysocki [this message]
2009-11-02 19:05 ` Rafael J. Wysocki
2009-11-02 21:19 ` Nigel Cunningham
2009-11-02 21:19 ` Nigel Cunningham
2009-11-03 11:30 ` Rafael J. Wysocki
2009-11-03 11:30 ` Rafael J. Wysocki
2009-11-03 21:12 ` Nigel Cunningham
2009-11-03 21:12 ` Nigel Cunningham
2009-11-03 22:00 ` Rafael J. Wysocki
2009-11-03 22:00 ` Rafael J. Wysocki
2009-11-12 12:33 ` using highmem for atomic copy of lowmem was " Pavel Machek
2009-11-12 12:33 ` Pavel Machek
2009-11-12 23:33 ` Rafael J. Wysocki
2009-11-12 23:33 ` Rafael J. Wysocki
2009-11-03 14:00 ` KOSAKI Motohiro
2009-11-03 14:00 ` KOSAKI Motohiro
2009-11-03 21:52 ` Rafael J. Wysocki
2009-11-03 21:52 ` Rafael J. Wysocki
2009-11-01 15:11 ` [PATCHv2 3/5] vmscan: Stop zone_reclaim()'s wrong swap_cluster_max usage KOSAKI Motohiro
2009-11-01 15:11 ` KOSAKI Motohiro
2009-11-01 17:51 ` Rik van Riel
2009-11-01 17:51 ` Rik van Riel
2009-11-02 0:40 ` Minchan Kim
2009-11-02 0:40 ` Minchan Kim
2009-11-01 15:12 ` [PATCHv2 4/5] vmscan: Kill sc.swap_cluster_max KOSAKI Motohiro
2009-11-01 15:12 ` KOSAKI Motohiro
2009-11-01 17:56 ` Rik van Riel
2009-11-01 17:56 ` Rik van Riel
2009-11-02 0:46 ` Minchan Kim
2009-11-02 0:46 ` Minchan Kim
2009-11-01 15:13 ` [PATCHv2 5/5][nit fix] vmscan Make consistent of reclaim bale out between do_try_to_free_page and shrink_zone KOSAKI Motohiro
2009-11-01 15:13 ` KOSAKI Motohiro
2009-11-01 17:58 ` Rik van Riel
2009-11-01 17:58 ` Rik van Riel
2009-11-02 0:48 ` Minchan Kim
2009-11-02 0:48 ` Minchan Kim
2009-11-02 0:35 ` [PATCHv2 1/5] vmscan: separate sc.swap_cluster_max and sc.nr_max_reclaim Minchan Kim
2009-11-02 0:35 ` Minchan Kim
2009-11-02 0:48 ` Minchan Kim
2009-11-02 0:48 ` Minchan Kim
2009-11-02 15:35 ` KOSAKI Motohiro
2009-11-02 15:35 ` KOSAKI Motohiro
2009-11-02 23:34 ` Minchan Kim
2009-11-02 23:34 ` Minchan Kim
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=200911022005.04076.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ncunningham@crca.org.au \
--cc=riel@redhat.com \
/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.