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,
_
next prev parent reply other threads:[~2004-03-01 9:52 UTC|newest]
Thread overview: 40+ 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
2005-05-19 6:24 ` 2.6.3-mm4 Greg KH
2004-02-27 8:35 ` 2.6.3-mm4 Jean Delvare
2005-05-19 6:24 ` 2.6.3-mm4 Jean Delvare
2004-02-27 18:16 ` 2.6.3-mm4 Mike Fedyk
2005-05-19 6:24 ` 2.6.3-mm4 Mike Fedyk
2004-02-27 19:59 ` 2.6.3-mm4 Jean Delvare
2005-05-19 6:24 ` 2.6.3-mm4 Jean Delvare
2004-02-29 7:51 ` 2.6.3-mm4 Mike Fedyk
2005-05-19 6:24 ` 2.6.3-mm4 Mike Fedyk
2004-02-29 10:11 ` 2.6.3-mm4 Jean Delvare
2005-05-19 6:24 ` 2.6.3-mm4 Jean Delvare
2004-02-27 16:48 ` 2.6.3-mm4 Prakash K. Cheemplavam
2005-05-19 6:24 ` 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 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.