All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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.