From: Con Kolivas <kernel@kolivas.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
linux list <linux-kernel@vger.kernel.org>,
ck list <ck@vds.kolivas.org>, Andrew Morton <akpm@osdl.org>,
Pavel Machek <pavel@ucw.cz>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: swsusp shrink_all_memory tweaks
Date: Sat, 25 Mar 2006 02:30:07 +1100 [thread overview]
Message-ID: <200603250230.08140.kernel@kolivas.org> (raw)
In-Reply-To: <200603241616.06687.rjw@sisk.pl>
On Saturday 25 March 2006 02:16, Rafael J. Wysocki wrote:
> On Friday 24 March 2006 08:07, Con Kolivas wrote:
> > On Tuesday 21 March 2006 05:46, Rafael J. Wysocki wrote:
> > > swsusp_shrink_memory() is still wrong, because it will always fail for
> > > image_size = 0. My bad, sorry.
> > >
> > > The appended patch (on top of yours) should fix that (hope I did it
> > > right this time).
> >
> > Well I discovered that if all the necessary memory is freed in one call
> > to shrink_all_memory we don't get the nice updating printout from
> > swsusp_shrink_memory telling us we're making progress. So instead of
> > modifying the function to call shrink_all_memory with the full amount
> > (and since we've botched swsusp_shrink_memory a few times between us), we
> > should limit it to a max of SHRINK_BITEs instead.
> >
> > This patch is fine standalone.
> >
> > Rafael, Pavel what do you think of this one?
>
> In principle it looks good to me, but when I tested the previous one I
> noticed shrink_all_memory() tended to return 0 prematurely (ie. when it was
> possible to free some more pages). It only happened if more than 50% of
> memory was occupied by application data.
>
> Unfortunately I couldn't find the reason.
Perhaps it was just trying to free up too much in one go. There are a number
of steps a mapped page needs to go through before being finally swapped and
there are a limited number of iterations over it. Limiting it to SHRINK_BITEs
at a time will probably improve that.
Cheers,
Con
WARNING: multiple messages have this Message-ID (diff)
From: Con Kolivas <kernel@kolivas.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
linux list <linux-kernel@vger.kernel.org>,
ck list <ck@vds.kolivas.org>, Andrew Morton <akpm@osdl.org>,
Pavel Machek <pavel@ucw.cz>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: swsusp shrink_all_memory tweaks
Date: Sat, 25 Mar 2006 02:30:07 +1100 [thread overview]
Message-ID: <200603250230.08140.kernel@kolivas.org> (raw)
In-Reply-To: <200603241616.06687.rjw@sisk.pl>
On Saturday 25 March 2006 02:16, Rafael J. Wysocki wrote:
> On Friday 24 March 2006 08:07, Con Kolivas wrote:
> > On Tuesday 21 March 2006 05:46, Rafael J. Wysocki wrote:
> > > swsusp_shrink_memory() is still wrong, because it will always fail for
> > > image_size = 0. My bad, sorry.
> > >
> > > The appended patch (on top of yours) should fix that (hope I did it
> > > right this time).
> >
> > Well I discovered that if all the necessary memory is freed in one call
> > to shrink_all_memory we don't get the nice updating printout from
> > swsusp_shrink_memory telling us we're making progress. So instead of
> > modifying the function to call shrink_all_memory with the full amount
> > (and since we've botched swsusp_shrink_memory a few times between us), we
> > should limit it to a max of SHRINK_BITEs instead.
> >
> > This patch is fine standalone.
> >
> > Rafael, Pavel what do you think of this one?
>
> In principle it looks good to me, but when I tested the previous one I
> noticed shrink_all_memory() tended to return 0 prematurely (ie. when it was
> possible to free some more pages). It only happened if more than 50% of
> memory was occupied by application data.
>
> Unfortunately I couldn't find the reason.
Perhaps it was just trying to free up too much in one go. There are a number
of steps a mapped page needs to go through before being finally swapped and
there are a limited number of iterations over it. Limiting it to SHRINK_BITEs
at a time will probably improve that.
Cheers,
Con
--
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:[~2006-03-24 15:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-19 15:31 [PATCH][1/3] mm: swsusp shrink_all_memory tweaks Con Kolivas
2006-03-19 15:31 ` Con Kolivas
2006-03-20 11:41 ` Nick Piggin
2006-03-20 11:41 ` Nick Piggin
2006-03-20 11:50 ` Con Kolivas
2006-03-20 11:50 ` Con Kolivas
2006-03-20 18:46 ` Rafael J. Wysocki
2006-03-20 18:46 ` Rafael J. Wysocki
2006-03-24 7:07 ` [PATCH] " Con Kolivas
2006-03-24 7:07 ` Con Kolivas
2006-03-24 15:16 ` Rafael J. Wysocki
2006-03-24 15:16 ` Rafael J. Wysocki
2006-03-24 15:30 ` Con Kolivas [this message]
2006-03-24 15:30 ` Con Kolivas
2006-03-24 16:14 ` Rafael J. Wysocki
2006-03-24 16:14 ` Rafael J. Wysocki
2006-03-30 17:12 ` Rafael J. Wysocki
2006-03-30 17:12 ` Rafael J. Wysocki
2006-03-30 18:37 ` Rafael J. Wysocki
2006-03-30 18:37 ` Rafael J. Wysocki
2006-03-30 20:38 ` Con Kolivas
2006-03-30 20:38 ` Con Kolivas
2006-03-30 20:57 ` Rafael J. Wysocki
2006-03-30 20:57 ` Rafael J. Wysocki
2006-03-27 12:24 ` Pavel Machek
2006-03-27 12:24 ` 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=200603250230.08140.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=ck@vds.kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=pavel@ucw.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.