linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@users.sourceforge.net>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Linux Memory Management <linux-mm@kvack.org>,
	Andrew Morton <akpm@osdl.org>, Michael Frank <mhf@linuxmail.org>
Subject: Re: Memory management in 2.6
Date: Tue, 20 Jan 2004 20:00:20 +1300	[thread overview]
Message-ID: <1074582020.2246.1.camel@laptop-linux> (raw)
In-Reply-To: <400CB3BD.4020601@cyberone.com.au>

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

Hi.

Michael Frank has written some scripts  we've used to stress test
software suspend. Perhaps you might be able to make some mileage from
them?

Regards,

Nigel

On Tue, 2004-01-20 at 17:51, Nick Piggin wrote:
> Hi,
> In the interest of helping improve 2.6 VM performance when
> under heavy swapping load, I'm putting together a few regression
> tests.
> 
> If anyone has any suggestions of workloads I could use, I will
> try to include them, or code them up if you want a simple concept
> tested. Also, any suggestions of what information I should gather?
> 
> loads should be runnable on about 64MB, preferably give decently
> repeatable results in under an hour.
> 
> I'll be happy to test patches. Here is one (results are a bit
> wild because it was only 1 run).
> 
> Nick
> 
> 
> ______________________________________________________________________
>  linux-2.6-npiggin/mm/vmscan.c |   30 +++++++++++++++++++++++-------
>  1 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff -puN mm/vmscan.c~vm-akpm-balance-pgdat mm/vmscan.c
> --- linux-2.6/mm/vmscan.c~vm-akpm-balance-pgdat	2004-01-17 20:35:39.000000000 +1100
> +++ linux-2.6-npiggin/mm/vmscan.c	2004-01-17 20:35:42.000000000 +1100
> @@ -941,11 +941,12 @@ static int balance_pgdat(pg_data_t *pgda
>  			int nr_mapped = 0;
>  			int max_scan;
>  			int to_reclaim;
> +			int reclaimed;
>  
>  			if (zone->all_unreclaimable && priority != DEF_PRIORITY)
>  				continue;
>  
> -			if (nr_pages && to_free > 0) {	/* Software suspend */
> +			if (nr_pages && nr_pages > 0) {	/* Software suspend */
>  				to_reclaim = min(to_free, SWAP_CLUSTER_MAX*8);
>  			} else {			/* Zone balancing */
>  				to_reclaim = zone->pages_high-zone->free_pages;
> @@ -953,28 +954,43 @@ static int balance_pgdat(pg_data_t *pgda
>  					continue;
>  			}
>  			zone->temp_priority = priority;
> -			all_zones_ok = 0;
>  			max_scan = zone->nr_inactive >> priority;
>  			if (max_scan < to_reclaim * 2)
>  				max_scan = to_reclaim * 2;
>  			if (max_scan < SWAP_CLUSTER_MAX)
>  				max_scan = SWAP_CLUSTER_MAX;
> -			to_free -= shrink_zone(zone, max_scan, GFP_KERNEL,
> +			reclaimed = shrink_zone(zone, max_scan, GFP_KERNEL,
>  					to_reclaim, &nr_mapped, ps, priority);
>  			if (i < ZONE_HIGHMEM) {
>  				reclaim_state->reclaimed_slab = 0;
>  				shrink_slab(max_scan + nr_mapped, GFP_KERNEL);
> -				to_free -= reclaim_state->reclaimed_slab;
> +				reclaimed += reclaim_state->reclaimed_slab;
>  			}
> +			to_free -= reclaimed;
>  			if (zone->all_unreclaimable)
>  				continue;
>  			if (zone->pages_scanned > zone->present_pages * 2)
>  				zone->all_unreclaimable = 1;
> +			/*
> +			 * If this scan failed to reclaim `to_reclaim' or more
> +			 * pages, we're getting into trouble.  Need to scan
> +			 * some more, and throttle kswapd.   Note that this zone
> +			 * may now have sufficient free pages due to freeing
> +			 * activity by some other process.   That's OK - we'll
> +			 * pick that info up on the next pass through the loop.
> +			 */
> +			if (reclaimed < to_reclaim)
> +				all_zones_ok = 0;
>  		}
> -		if (all_zones_ok)
> -			break;
>  		if (to_free > 0)
> -			blk_congestion_wait(WRITE, HZ/10);
> +			continue;	/* swsusp: need to do more work */
> +		if (all_zones_ok)
> +			break;		/* kswapd: all done */
> +		/*
> +		 * OK, kswapd is getting into trouble.  Take a nap, then take
> +		 * another pass across the zones.
> +		 */
> +		blk_congestion_wait(WRITE, HZ/10);
>  	}
>  
>  	for (i = 0; i < pgdat->nr_zones; i++) {
> 
> _
-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2004-01-20  6:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-20  4:51 Nick Piggin
2004-01-20  4:58 ` Andrew Morton
2004-01-20  5:05   ` Nick Piggin
2004-01-20 13:11     ` Roger Luethi
2004-01-20  7:00 ` Nigel Cunningham [this message]
2004-01-20  7:19   ` Michael Frank
2004-01-20  7:37     ` Nick Piggin
     [not found] <20040127162346.37b75f6c.cliffw@osdl.org>
     [not found] ` <40185564.8020709@cyberone.com.au>
2004-01-29  0:54   ` Memory Management " Nick Piggin

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=1074582020.2246.1.camel@laptop-linux \
    --to=ncunningham@users.sourceforge.net \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    --cc=mhf@linuxmail.org \
    --cc=piggin@cyberone.com.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox