linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Nigel Cunningham <ncunningham@crca.org.au>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	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: Tue, 3 Nov 2009 12:30:20 +0100	[thread overview]
Message-ID: <200911031230.20344.rjw@sisk.pl> (raw)
In-Reply-To: <4AEF4CF1.3020500@crca.org.au>

On Monday 02 November 2009, Nigel Cunningham wrote:
> Hi.

Hi,

> KOSAKI Motohiro wrote:
> >> 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.
> > following incremental patch prevent highmem reclaim perfectly. Is it enough?
> 
> (Disclaimer: I don't think about highmem a lot any more, and might have
> forgotten some of the details, or swsusp's algorithms might have
> changed. Rafael might need to correct some of this...)
> 
> Imagine that you have a system with 1000 pages of lowmem and 5000 pages
> of highmem. Of these, 950 lowmem pages are in use and 500 highmem pages
> are in use.
> 
> In order to to be able to save an image, we need to be able to do an
> atomic copy of those lowmem pages.
> 
> You might think that we could just copy everything into the spare
> highmem pages, but we can't because mapping and unmapping the highmem
> pages as we copy the data will leave us with an inconsistent copy.

This isn't the case any more for the mainline hibernate code.  We use highmem
for storing image data as well as lowmem.

Thanks,
Rafael

--
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-11-03 11:29 UTC|newest]

Thread overview: 32+ 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:09 ` [PATCHv2 2/5] vmscan: Kill hibernation specific reclaim logic and unify it KOSAKI Motohiro
2009-11-01 15:12   ` Rik van Riel
2009-11-01 21:38   ` Rafael J. Wysocki
2009-11-02 15:35     ` KOSAKI Motohiro
2009-11-02 19:03       ` Rafael J. Wysocki
2009-11-03 14:00         ` KOSAKI Motohiro
2009-11-03 21:51           ` Rafael J. Wysocki
2009-11-01 22:01   ` Nigel Cunningham
2009-11-02 15:35     ` KOSAKI Motohiro
2009-11-02 19:05       ` Rafael J. Wysocki
2009-11-02 21:19       ` Nigel Cunningham
2009-11-03 11:30         ` Rafael J. Wysocki [this message]
2009-11-03 21:12           ` Nigel Cunningham
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 23:33                 ` Rafael J. Wysocki
2009-11-03 14:00         ` KOSAKI Motohiro
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 17:51   ` Rik van Riel
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 17:56   ` Rik van Riel
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 17:58   ` Rik van Riel
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:48   ` Minchan Kim
2009-11-02 15:35   ` KOSAKI Motohiro
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=200911031230.20344.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox