From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Fabio Comolli <fabio.comolli@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Userland swsusp failure (mm-related)
Date: Wed, 12 Apr 2006 07:29:23 +0200 [thread overview]
Message-ID: <200604120729.24489.rjw@sisk.pl> (raw)
In-Reply-To: <200604120010.09848.rjw@sisk.pl>
Hi,
On Wednesday 12 April 2006 00:10, Rafael J. Wysocki wrote:
> On Tuesday 11 April 2006 23:36, Pavel Machek wrote:
> > > > Rafael J. Wysocki wrote:
> > > > >>>Well, it looks like we didn't free enough RAM for suspend in this case.
> > > > >>>Unfortunately we were below the min watermark for ZONE_NORMAL and
> > > > >>>we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
> > > > >>>ZONE_DMA in this case?).
> > > > >>>
> > > > >>>I think we can safely ignore the watermarks in swsusp, so probably
> > > > >>>we can set PF_MEMALLOC for the current task temporarily and reset
> > > > >>>it when we have allocated memory. Pavel, what do you think?
> > > > >>
> > > > >>Seems little hacky but okay to me.
> > > > >>
> > > > >>Should not fixing "how much to free" computation to free a bit more be
> > > > >>enough to handle this?
> > > > >
> > > > >
> > > > > Yes, but in that case we'll leave some memory unused. ;-)
> > > > >
> > > >
> > > > Probably doesn't fall back to ZONE_DMA because of lowmem reserve.
> > > > Yes, PF_MEMALLOC sounds like it might do what you want. A little
> > > > hackish perhaps, but better than putting swsusp special cases
> > > > into page_alloc.c.
> > >
> > > The appended patch contains the changes I'd like to make. Pavel, is that
> > > acceptable?
> >
> > Why is PF_MEMALLOC only neccessary for pagedir allocations, and not
> > for normal page allocations, too?
>
> Right, we'll need it untli we finally free the image, so I think it should be
> set/reset in disk.c:pm_suspend_disk().
>
> However, there's a problem with this approach wrt the userland suspend, because
> we'd have to keep PF_MEMALLOC set accross ioctls and I wouldn't like to do
> this.
>
> Well, the alternative solution would be to take the ZONE_DMA's lowmem reserve
> into account in our free memory computations.
OK, the appended patch subtracts each zone's lowmem reserve for ZONE_NORMAL
from the number of free pages because we are going to allocate from the normal
zone and won't be able to use the lowmem reserves.
Please have a look.
Greetings,
Rafael
---
kernel/power/swsusp.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.17-rc1-mm2/kernel/power/swsusp.c
===================================================================
--- linux-2.6.17-rc1-mm2.orig/kernel/power/swsusp.c 2006-04-12 07:09:20.000000000 +0200
+++ linux-2.6.17-rc1-mm2/kernel/power/swsusp.c 2006-04-12 07:11:09.000000000 +0200
@@ -192,8 +192,10 @@ int swsusp_shrink_memory(void)
PAGES_FOR_IO;
tmp = size;
for_each_zone (zone)
- if (!is_highmem(zone))
+ if (!is_highmem(zone) && zone->present_pages > 0) {
tmp -= zone->free_pages;
+ tmp += zone->lowmem_reserve[ZONE_NORMAL];
+ }
if (tmp > 0) {
tmp = shrink_all_memory(SHRINK_BITE);
if (!tmp)
prev parent reply other threads:[~2006-04-12 5:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b637ec0b0604080537s55e63544r8bb63c887e81ecaf@mail.gmail.com>
2006-04-08 15:16 ` Userland swsusp failure (mm-related) Rafael J. Wysocki
2006-04-08 16:15 ` Pavel Machek
2006-04-08 22:47 ` Rafael J. Wysocki
2006-04-08 23:24 ` Con Kolivas
2006-04-09 20:36 ` shrink_all_memory tweaks (was: Re: Userland swsusp failure (mm-related)) Rafael J. Wysocki
2006-04-09 23:23 ` Con Kolivas
2006-04-11 17:06 ` Rafael J. Wysocki
2006-04-13 12:42 ` Con Kolivas
2006-04-13 13:54 ` Rafael J. Wysocki
2006-04-13 14:01 ` Con Kolivas
2006-04-09 1:51 ` Userland swsusp failure (mm-related) Nick Piggin
2006-04-11 21:33 ` Rafael J. Wysocki
2006-04-11 21:36 ` Pavel Machek
2006-04-11 22:10 ` Rafael J. Wysocki
2006-04-12 5:29 ` Rafael J. Wysocki [this message]
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=200604120729.24489.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=fabio.comolli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=pavel@ucw.cz \
/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.