public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Mike Fedyk <mfedyk@matchmail.com>, Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4)
Date: Mon, 01 Mar 2004 20:52:23 +1100	[thread overview]
Message-ID: <404307D7.8090102@cyberone.com.au> (raw)
In-Reply-To: <4042FE0D.5030603@cyberone.com.au>

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



Nick Piggin wrote:

>
>
> Nick Piggin wrote:
>
>>
>> There are a few things backed out now in 2.6.4-rc1-mm1, and quite a
>> few other changes. I hope we can trouble you to test 2.6.4-rc1-mm1?
>>
>> Tell me, do you have highmem enabled on this system? If so, swapping
>> might be explained by the batching patch. With it, a small highmem
>> zone could possibly place quite a lot more pressure on a large
>> ZONE_NORMAL.
>>
>> 2.6.4-rc1-mm1 sould do much better here.
>
>
>
> Gah no. It would have the same problem actually, if that is indeed
> what is happening.
>
> It will take a bit more work to solve this in rc1-mm1. You would
> probably want to explicitly use incremental min limits for kswapd.
>
> (background info in kswapd-avoid-higher-zones.patch)
>
>

Mike, it would be interesting if you could try out the 2.6.4-rc1-mm1
VM patches before and after this little beauty.

Andrew, I think you had kswapd scanning in the direction opposite the
one indicated by your comments. Or maybe I've just confused myself?


[-- Attachment #2: vm-kswapd-incremental-min.patch --]
[-- Type: text/plain, Size: 2585 bytes --]

 linux-2.6-npiggin/mm/vmscan.c |   36 ++++++++++++++++++++++++------------
 1 files changed, 24 insertions(+), 12 deletions(-)

diff -puN mm/vmscan.c~vm-kswapd-incremental-min mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-kswapd-incremental-min	2004-03-01 20:29:18.000000000 +1100
+++ linux-2.6-npiggin/mm/vmscan.c	2004-03-01 20:44:26.000000000 +1100
@@ -889,6 +889,8 @@ out:
 	return ret;
 }
 
+extern int sysctl_lower_zone_protection;
+
 /*
  * For kswapd, balance_pgdat() will work across all this node's zones until
  * they are all at pages_high.
@@ -907,12 +909,9 @@ out:
  * dead and from now on, only perform a short scan.  Basically we're polling
  * the zone for when the problem goes away.
  *
- * kswapd scans the zones in the highmem->normal->dma direction.  It skips
- * zones which have free_pages > pages_high, but once a zone is found to have
- * free_pages <= pages_high, we scan that zone and the lower zones regardless
- * of the number of free pages in the lower zones.  This interoperates with
- * the page allocator fallback scheme to ensure that aging of pages is balanced
- * across the zones.
+ * balance_pgdat tries to coexist with the INFAMOUS "incremental min" by
+ * trying to free lower zones a bit harder if higher zones are low too.
+ * See mm/page_alloc.c
  */
 static int balance_pgdat(pg_data_t *pgdat, int nr_pages, struct page_state *ps)
 {
@@ -930,24 +929,37 @@ static int balance_pgdat(pg_data_t *pgda
 	}
 
 	for (priority = DEF_PRIORITY; priority; priority--) {
+		unsigned long min;
 		int all_zones_ok = 1;
 		int pages_scanned = 0;
+		min = 0; /* Shut up gcc */
 
-		for (i = pgdat->nr_zones - 1; i >= 0; i--) {
+		for (i = 0; i < pgdat->nr_zones; i++) {
 			struct zone *zone = pgdat->node_zones + i;
 			int total_scanned = 0;
 			int max_scan;
 			int reclaimed;
 
-			if (zone->all_unreclaimable && priority != DEF_PRIORITY)
-				continue;
-
 			if (nr_pages == 0) {	/* Not software suspend */
-				if (zone->free_pages <= zone->pages_high)
-					all_zones_ok = 0;
+				/* "incremental min" right here */
 				if (all_zones_ok)
+					min = zone->pages_high;
+				else
+					min += zone->pages_high;
+
+				if (zone->free_pages <= min)
+					all_zones_ok = 0;
+				else
 					continue;
+
+				min += zone->pages_high *
+						sysctl_lower_zone_protection;
 			}
+
+			/* Note: this is checked *after* min is incremented */
+			if (zone->all_unreclaimable && priority != DEF_PRIORITY)
+				continue;
+
 			zone->temp_priority = priority;
 			max_scan = zone->nr_inactive >> priority;
 			reclaimed = shrink_zone(zone, max_scan, GFP_KERNEL,

_

  reply	other threads:[~2004-03-01  9:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-26  2:55 2.6.3-mm4 Andrew Morton
2004-02-26  8:22 ` 2.6.3-mm4 Alexander Hoogerhuis
2004-02-26  8:48   ` 2.6.3-mm4 Marc-Christian Petersen
2004-02-26  8:51 ` 2.6.3-mm4 Nuno Silva
2004-02-27  0:48   ` 2.6.3-mm4 Greg KH
2004-02-26 15:50 ` 2.6.3-mm4 David Martínez Moreno
2004-02-26 15:59   ` 2.6.3-mm4 Christoph Hellwig
2004-02-26 16:30 ` 2.6.3-mm4 (compile stats) John Cherry
2004-02-26 18:59   ` Mike Fedyk
2004-02-26 19:26     ` John Cherry
2004-02-26 18:50 ` 2.6.3-mm4 Matthias Hentges
2004-02-26 23:35 ` 2.6.3-mm4, sensors broken Prakash K. Cheemplavam
2004-02-27  0:03   ` Andrew Morton
2004-02-27  8:58     ` Prakash K. Cheemplavam
2004-02-27  0:11 ` 2.6.3-mm4 J.A. Magallon
2004-02-27  0:46   ` 2.6.3-mm4 Greg KH
2004-02-27  8:35     ` 2.6.3-mm4 Jean Delvare
2004-02-27 18:16       ` 2.6.3-mm4 Mike Fedyk
2004-02-27 19:59         ` 2.6.3-mm4 Jean Delvare
2004-02-29  7:51           ` 2.6.3-mm4 Mike Fedyk
2004-02-29 10:11             ` 2.6.3-mm4 Jean Delvare
2004-02-27 16:48     ` 2.6.3-mm4 Prakash K. Cheemplavam
2004-02-27  9:00   ` 2.6.3-mm4 Prakash K. Cheemplavam
2004-02-27 23:51 ` 2.6.3-mm4 Adrian Bunk
2004-03-01  8:25 ` MM VM patches was: 2.6.3-mm4 Mike Fedyk
2004-03-01  8:44   ` Nick Piggin
2004-03-01  9:05     ` Mike Fedyk
2004-03-01  9:27       ` Nick Piggin
2004-03-01  9:47         ` Mike Fedyk
2004-03-01  9:10     ` Nick Piggin
2004-03-01  9:52       ` Nick Piggin [this message]
2004-03-01 10:18         ` [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4) Andrew Morton
2004-03-01 10:29           ` 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=404307D7.8090102@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    /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