All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
	Fabio Comolli <fabio.comolli@gmail.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: shrink_all_memory tweaks (was: Re: Userland swsusp failure (mm-related))
Date: Thu, 13 Apr 2006 22:42:57 +1000	[thread overview]
Message-ID: <200604132242.57664.kernel@kolivas.org> (raw)
In-Reply-To: <200604111906.32535.rjw@sisk.pl>

On Wednesday 12 April 2006 03:06, Rafael J. Wysocki wrote:
> The patch is appended.
>
> In shrink_all_memory() I try to free exactly as many pages as the caller
> asks for, preferably in one shot, starting from easier targets.  If slabs
> are huge, they are most likely to have enough pages to reclaim.  The
> inactive lists are next (the zones with more inactive pages go first) etc. 
> However, since each pass potentially requires more work, the number of
> pages to scan is decreased as the pages are reclaimed which seems to make
> the shrinking of memory go more smoothly.
>
> I've been testing it on an x86_64 box for some time and it seems to behave
> quite reasonably, eg. it usually makes the actual image size very close to
> the value of image_size and if you set image_size to 0, it shrinks
> everything almost totally.

Great. Looks pretty good. See comments.

> ---

>  #ifdef CONFIG_PM
>  /*
> - * Try to free `nr_pages' of memory, system-wide.  Returns the number of
> freed - * pages.
> + * Helper function for shrink_all_memory().  Tries to reclaim 'nr_pages'
> pages + * from LRU lists system-wide, for given pass and priority, and
> returns the + * number of reclaimed pages
> + *
> + * For pass > 3 we also try to shrink the LRU lists that contain a few
> pages + */
> +unsigned long shrink_all_zones(unsigned long nr_pages, int pass, int prio,
> +				struct scan_control *sc)

I like how this moves all suspend vm functions out of the generic functions 
even more than I managed to.

> +	int swappiness = vm_swappiness, pass;
> +	struct reclaim_state reclaim_state;
> +	struct zone *zone;
> +	struct scan_control sc = {
> +		.gfp_mask = GFP_KERNEL,
> +		.may_swap = 1,
> +		.swap_cluster_max = nr_pages,
> +		.may_writepage = 1,
>  	};

This is not quite right at maintaining the original semantics I was proposing. 
Since you are iterating over all priorities, setting may_swap means you will 
reclaim mapped ram on the earlier passes once priority gets low enough. 
Setting vm_swappiness temporarily to 100 is unncecessary. You should set 
may_swap to 0 and set it to 1 on passes 3+.

Otherwise, looks good, thanks!

-- 
-ck

  reply	other threads:[~2006-04-13 12:43 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 [this message]
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

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=200604132242.57664.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=fabio.comolli@gmail.com \
    --cc=linux-kernel@vger.kernel.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.