From: Andy Whitcroft <apw@shadowen.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Andrew Morton <akpm@linux-foundation.org>,
pavel@suse.cz, linux-kernel@vger.kernel.org,
linux-pm@lists.osdl.org,
Matt Tolentino <matthew.e.tolentino@intel.com>,
Dave Hansen <haveblue@us.ibm.com>,
linux-mm@kvack.org, Mel Gorman <mel@skynet.ie>
Subject: Re: [PATCH] hibernation should work ok with memory hotplug
Date: Mon, 3 Nov 2008 23:39:17 +0000 [thread overview]
Message-ID: <20081103233917.GF10325@brain> (raw)
In-Reply-To: <1225751665.12673.511.camel@nimitz>
On Mon, Nov 03, 2008 at 02:34:25PM -0800, Dave Hansen wrote:
> On Mon, 2008-11-03 at 23:24 +0100, Rafael J. Wysocki wrote:
> > On Monday, 3 of November 2008, Dave Hansen wrote:
> > > On Mon, 2008-11-03 at 12:51 -0800, Andrew Morton wrote:
> > > > On Wed, 29 Oct 2008 13:25:00 +0100
> > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > On Wednesday, 29 of October 2008, Pavel Machek wrote:
> > > > > >
> > > > > > hibernation + memory hotplug was disabled in kconfig because we could
> > > > > > not handle hibernation + sparse mem at some point. It seems to work
> > > > > > now, so I guess we can enable it.
> > > > >
> > > > > OK, if "it seems to work now" means that it has been tested and confirmed to
> > > > > work, no objection from me.
> > > >
> > > > yes, that was not a terribly confidence-inspiring commit message.
> > > >
> > > > 3947be1969a9ce455ec30f60ef51efb10e4323d1 said "For now, disable memory
> > > > hotplug when swsusp is enabled. There's a lot of churn there right
> > > > now. We'll fix it up properly once it calms down." which is also
> > > > rather rubbery.
> > > >
> > > > Cough up, guys: what was the issue with memory hotplug and swsusp, and
> > > > is it indeed now fixed?
> > >
> > > I suck. That commit message was horrid and I'm racking my brain now to
> > > remember what I meant. Don't end up like me, kids.
> > >
> > > I've attached the message that I sent to the swsusp folks. I never got
> > > a reply from that as far as I can tell.
> > >
> > > http://sourceforge.net/mailarchive/forum.php?thread_name=1118682535.22631.22.camel%40localhost&forum_name=lhms-devel
> > >
> > > As I look at it now, it hasn't improved much since 2005. Take a look at
> > > kernel/power/snapshot.c::copy_data_pages(). It still assumes that the
> > > list of zones that a system has is static. Memory hotplug needs to be
> > > excluded while that operation is going on.
> >
> > This operation is carried out on one CPU with interrupts disabled. Is that
> > not enough?
>
> If that's true then you don't need any locking for anything at all,
> right?
>
> All of the changes I was talking about occur inside the kernel and code
> has to run for it to happen. So, if you are saying that absolutely no
> other code on the system can possibly run, then it should be OK.
>
> > > page_is_saveable() checks for pfn_valid(). But, with memory hotplug,
> > > things can become invalid at any time since no references are held or
> > > taken on the page. Or, a page that *was* invalid may become valid and
> > > get missed.
> >
> > Can that really happen given the conditions above?
>
> Nope.
>
> But, as I think about it, there is another issue that we need to
> address, CONFIG_NODES_SPAN_OTHER_NODES.
>
> A node might have a node_start_pfn=0 and a node_end_pfn=100 (and it may
> have only one zone). But, there may be another node with
> node_start_pfn=10 and a node_end_pfn=20. This loop:
>
> for_each_zone(zone) {
> ...
> for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++)
> if (page_is_saveable(zone, pfn))
> memory_bm_set_bit(orig_bm, pfn);
> }
>
> will walk over the smaller node's pfn range multiple times. Is this OK?
>
> I think all you have to do to fix it is check page_zone(page) == zone
> and skip out if they don't match.
>
> Andy, does anything else stick out to you?
I agree that there needs to be a check for being in the zone there to
avoid the overlapping nodes issue. Also need to make sure when
constructing that check we check for pfn_valid before looking at the
page to avoid holes in the memmap.
-apw
WARNING: multiple messages have this Message-ID (diff)
From: Andy Whitcroft <apw@shadowen.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Andrew Morton <akpm@linux-foundation.org>,
pavel@suse.cz, linux-kernel@vger.kernel.org,
linux-pm@lists.osdl.org,
Matt Tolentino <matthew.e.tolentino@intel.com>,
Dave Hansen <haveblue@us.ibm.com>,
linux-mm@kvack.org, Mel Gorman <mel@skynet.ie>
Subject: Re: [PATCH] hibernation should work ok with memory hotplug
Date: Mon, 3 Nov 2008 23:39:17 +0000 [thread overview]
Message-ID: <20081103233917.GF10325@brain> (raw)
In-Reply-To: <1225751665.12673.511.camel@nimitz>
On Mon, Nov 03, 2008 at 02:34:25PM -0800, Dave Hansen wrote:
> On Mon, 2008-11-03 at 23:24 +0100, Rafael J. Wysocki wrote:
> > On Monday, 3 of November 2008, Dave Hansen wrote:
> > > On Mon, 2008-11-03 at 12:51 -0800, Andrew Morton wrote:
> > > > On Wed, 29 Oct 2008 13:25:00 +0100
> > > > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > > > On Wednesday, 29 of October 2008, Pavel Machek wrote:
> > > > > >
> > > > > > hibernation + memory hotplug was disabled in kconfig because we could
> > > > > > not handle hibernation + sparse mem at some point. It seems to work
> > > > > > now, so I guess we can enable it.
> > > > >
> > > > > OK, if "it seems to work now" means that it has been tested and confirmed to
> > > > > work, no objection from me.
> > > >
> > > > yes, that was not a terribly confidence-inspiring commit message.
> > > >
> > > > 3947be1969a9ce455ec30f60ef51efb10e4323d1 said "For now, disable memory
> > > > hotplug when swsusp is enabled. There's a lot of churn there right
> > > > now. We'll fix it up properly once it calms down." which is also
> > > > rather rubbery.
> > > >
> > > > Cough up, guys: what was the issue with memory hotplug and swsusp, and
> > > > is it indeed now fixed?
> > >
> > > I suck. That commit message was horrid and I'm racking my brain now to
> > > remember what I meant. Don't end up like me, kids.
> > >
> > > I've attached the message that I sent to the swsusp folks. I never got
> > > a reply from that as far as I can tell.
> > >
> > > http://sourceforge.net/mailarchive/forum.php?thread_name=1118682535.22631.22.camel%40localhost&forum_name=lhms-devel
> > >
> > > As I look at it now, it hasn't improved much since 2005. Take a look at
> > > kernel/power/snapshot.c::copy_data_pages(). It still assumes that the
> > > list of zones that a system has is static. Memory hotplug needs to be
> > > excluded while that operation is going on.
> >
> > This operation is carried out on one CPU with interrupts disabled. Is that
> > not enough?
>
> If that's true then you don't need any locking for anything at all,
> right?
>
> All of the changes I was talking about occur inside the kernel and code
> has to run for it to happen. So, if you are saying that absolutely no
> other code on the system can possibly run, then it should be OK.
>
> > > page_is_saveable() checks for pfn_valid(). But, with memory hotplug,
> > > things can become invalid at any time since no references are held or
> > > taken on the page. Or, a page that *was* invalid may become valid and
> > > get missed.
> >
> > Can that really happen given the conditions above?
>
> Nope.
>
> But, as I think about it, there is another issue that we need to
> address, CONFIG_NODES_SPAN_OTHER_NODES.
>
> A node might have a node_start_pfn=0 and a node_end_pfn=100 (and it may
> have only one zone). But, there may be another node with
> node_start_pfn=10 and a node_end_pfn=20. This loop:
>
> for_each_zone(zone) {
> ...
> for (pfn = zone->zone_start_pfn; pfn < max_zone_pfn; pfn++)
> if (page_is_saveable(zone, pfn))
> memory_bm_set_bit(orig_bm, pfn);
> }
>
> will walk over the smaller node's pfn range multiple times. Is this OK?
>
> I think all you have to do to fix it is check page_zone(page) == zone
> and skip out if they don't match.
>
> Andy, does anything else stick out to you?
I agree that there needs to be a check for being in the zone there to
avoid the overlapping nodes issue. Also need to make sure when
constructing that check we check for pfn_valid before looking at the
page to avoid holes in the memmap.
-apw
--
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:[~2008-11-03 23:39 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-29 10:59 [PATCH] hibernation should work ok with memory hotplug Pavel Machek
2008-10-29 12:25 ` Rafael J. Wysocki
2008-11-03 20:51 ` Andrew Morton
2008-11-03 20:51 ` Andrew Morton
2008-11-03 21:18 ` [linux-pm] " Nigel Cunningham
2008-11-03 21:18 ` Nigel Cunningham
2008-11-03 21:21 ` Dave Hansen
2008-11-03 22:24 ` Rafael J. Wysocki
2008-11-03 22:24 ` Rafael J. Wysocki
2008-11-03 22:34 ` Dave Hansen
2008-11-03 22:34 ` Dave Hansen
2008-11-03 23:05 ` Rafael J. Wysocki
2008-11-03 23:05 ` Rafael J. Wysocki
2008-11-03 23:10 ` Dave Hansen
2008-11-03 23:10 ` Dave Hansen
2008-11-04 0:29 ` Rafael J. Wysocki
2008-11-04 0:29 ` Rafael J. Wysocki
2008-11-04 0:52 ` Dave Hansen
2008-11-04 0:52 ` Dave Hansen
2008-11-03 23:39 ` Andy Whitcroft [this message]
2008-11-03 23:39 ` Andy Whitcroft
2008-11-04 4:02 ` [linux-pm] " Nigel Cunningham
2008-11-04 4:02 ` Nigel Cunningham
2008-11-04 7:08 ` Rafael J. Wysocki
2008-11-04 7:08 ` Rafael J. Wysocki
2008-11-04 7:36 ` Dave Hansen
2008-11-04 7:36 ` Dave Hansen
2008-11-04 8:54 ` Rafael J. Wysocki
2008-11-04 8:54 ` Rafael J. Wysocki
2008-11-04 15:21 ` Dave Hansen
2008-11-04 15:21 ` Dave Hansen
2008-11-04 15:35 ` Rafael J. Wysocki
2008-11-04 15:35 ` Rafael J. Wysocki
2008-11-04 15:39 ` Dave Hansen
2008-11-04 15:39 ` Dave Hansen
2008-11-04 16:34 ` Rafael J. Wysocki
2008-11-04 16:34 ` Rafael J. Wysocki
2008-11-04 16:59 ` Dave Hansen
2008-11-05 0:38 ` KAMEZAWA Hiroyuki
2008-11-05 0:38 ` KAMEZAWA Hiroyuki
2008-11-05 11:08 ` Rafael J. Wysocki
2008-11-05 11:08 ` Rafael J. Wysocki
2008-11-06 0:14 ` KAMEZAWA Hiroyuki
2008-11-06 0:14 ` KAMEZAWA Hiroyuki
2008-11-06 0:28 ` Dave Hansen
2008-11-06 0:28 ` Dave Hansen
2008-11-06 0:53 ` KAMEZAWA Hiroyuki
2008-11-06 0:53 ` KAMEZAWA Hiroyuki
2008-11-06 2:03 ` Nigel Cunningham
2008-11-06 2:03 ` Nigel Cunningham
2008-11-06 2:13 ` KAMEZAWA Hiroyuki
2008-11-06 2:13 ` KAMEZAWA Hiroyuki
2008-11-06 14:47 ` Alan Stern
2008-11-06 14:47 ` Alan Stern
2008-11-07 1:09 ` KAMEZAWA Hiroyuki
2008-11-07 1:09 ` KAMEZAWA Hiroyuki
2008-11-07 1:09 ` KAMEZAWA Hiroyuki
2008-11-06 8:47 ` Pavel Machek
2008-11-06 8:47 ` Pavel Machek
2008-11-06 1:17 ` KAMEZAWA Hiroyuki
2008-11-06 1:17 ` KAMEZAWA Hiroyuki
2008-11-06 1:43 ` Nigel Cunningham
2008-11-06 1:43 ` Nigel Cunningham
2008-11-06 1:54 ` KAMEZAWA Hiroyuki
2008-11-06 1:54 ` KAMEZAWA Hiroyuki
2008-11-06 1:59 ` KAMEZAWA Hiroyuki
2008-11-06 1:59 ` KAMEZAWA Hiroyuki
2008-11-06 2:00 ` Nigel Cunningham
2008-11-06 2:00 ` Nigel Cunningham
2008-11-06 2:07 ` KAMEZAWA Hiroyuki
2008-11-06 2:07 ` KAMEZAWA Hiroyuki
2008-11-06 3:12 ` KAMEZAWA Hiroyuki
2008-11-06 3:12 ` KAMEZAWA Hiroyuki
2008-11-06 3:28 ` Yasunori Goto
2008-11-06 3:28 ` Yasunori Goto
2008-11-06 6:04 ` KAMEZAWA Hiroyuki
2008-11-06 6:04 ` KAMEZAWA Hiroyuki
2008-11-06 14:48 ` Alan Stern
2008-11-06 14:48 ` Alan Stern
2008-11-06 14:48 ` Alan Stern
2008-11-06 20:46 ` Nigel Cunningham
2008-11-06 20:46 ` Nigel Cunningham
2008-11-06 9:12 ` Pavel Machek
2008-11-06 9:12 ` Pavel Machek
2008-11-06 9:12 ` KAMEZAWA Hiroyuki
2008-11-06 9:12 ` KAMEZAWA Hiroyuki
2008-11-06 9:26 ` Nigel Cunningham
2008-11-06 9:26 ` Nigel Cunningham
2008-11-06 14:43 ` Alan Stern
2008-11-06 14:43 ` Alan Stern
2008-11-06 14:43 ` Alan Stern
2008-11-04 7:09 ` Dave Hansen
2008-11-04 7:09 ` Dave Hansen
2008-11-04 7:30 ` Nigel Cunningham
2008-11-04 7:30 ` Nigel Cunningham
2008-11-04 7:53 ` Dave Hansen
2008-11-04 7:53 ` Dave Hansen
2008-11-05 9:10 ` Nigel Cunningham
2008-11-05 9:10 ` Nigel Cunningham
2008-11-05 10:58 ` Rafael J. Wysocki
2008-11-05 10:58 ` Rafael J. Wysocki
2008-11-05 16:23 ` Dave Hansen
2008-11-05 16:23 ` Dave Hansen
2008-11-06 12:28 ` Pavel Machek
2008-11-06 12:28 ` Pavel Machek
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=20081103233917.GF10325@brain \
--to=apw@shadowen.org \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@lists.osdl.org \
--cc=matthew.e.tolentino@intel.com \
--cc=mel@skynet.ie \
--cc=pavel@suse.cz \
--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.