linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org, Nikita@Namesys.COM
Subject: Re: [BENCHMARKS] Namesys VM patches improve kbuild
Date: Thu, 22 Jan 2004 17:54:02 +1100	[thread overview]
Message-ID: <400F738A.40505@cyberone.com.au> (raw)
In-Reply-To: <20040121223608.1ea30097.akpm@osdl.org>

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



Andrew Morton wrote:

>Nick Piggin <piggin@cyberone.com.au> wrote:
>
>>Hi,
>>
>>The two namesys patches help kbuild quite a lot here.
>>http://www.kerneltrap.org/~npiggin/vm/1/
>>
>>The patches can be found at
>>http://thebsh.namesys.com/snapshots/LATEST/extra/
>>
>
>I played with these back in July.  Had a few stability problems then but
>yes, they did speed up some workloads a lot.
>
>
>
>>I don't have much to comment on the patches. They do include
>>some cleanup stuff which should be broken out.
>>
>
>Yup.  <dig, dig>  See below - it's six months old though.
>
>
>>I don't really understand the dont-rotate-active-list patch:
>>I don't see why we're losing LRU information because the pages
>>that go to the head of the active list get their referenced
>>bits cleared.
>>
>
>Yes, I do think that the "LRU" is a bit of a misnomer - it's very
>approximate and only really suits simple workloads.  I suspect that once
>things get hot and heavy the "lru" is only four-deep:
>unreferenced/inactive, referenced/inactive, unreferenced/active and
>referenced/active.
>

Yep that was my thinking.

>
>Can you test the patches separately, see what bits are actually helping?
>


OK, I'll see how the second chance one alone does. By the way, what
do you think of this? Did I miss something non obvious?

Seems to make little difference on the benchmarks. Without the patch,
the active list would generally be attacked more aggressively.


[-- Attachment #2: vm-fix-shrink-zone.patch --]
[-- Type: text/plain, Size: 2582 bytes --]


Use the actual number of pages difference when trying to keep the inactive
list 1/2 the size of the active list (1/3 the size of all pages) instead of
a meaningless ratio.


 linux-2.6-npiggin/mm/vmscan.c |   37 +++++++++++++++++++------------------
 1 files changed, 19 insertions(+), 18 deletions(-)

diff -puN mm/vmscan.c~vm-fix-shrink-zone mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-fix-shrink-zone	2004-01-22 14:47:25.000000000 +1100
+++ linux-2.6-npiggin/mm/vmscan.c	2004-01-22 16:25:04.000000000 +1100
@@ -745,38 +745,39 @@ static int
 shrink_zone(struct zone *zone, int max_scan, unsigned int gfp_mask,
 	const int nr_pages, int *nr_mapped, struct page_state *ps, int priority)
 {
-	unsigned long ratio;
+	unsigned long imbalance;
+	unsigned long nr_refill_inact;
 
 	/*
 	 * Try to keep the active list 2/3 of the size of the cache.  And
 	 * make sure that refill_inactive is given a decent number of pages.
 	 *
-	 * The "ratio+1" here is important.  With pagecache-intensive workloads
-	 * the inactive list is huge, and `ratio' evaluates to zero all the
-	 * time.  Which pins the active list memory.  So we add one to `ratio'
-	 * just to make sure that the kernel will slowly sift through the
-	 * active list.
+	 * Keeping imbalance > 0 is important.  With pagecache-intensive loads
+	 * the inactive list is huge, and imbalance evaluates to zero all the
+	 * time which would pin the active list memory.
 	 */
-	ratio = (unsigned long)nr_pages * zone->nr_active /
-				((zone->nr_inactive | 1) * 2);
-	atomic_add(ratio+1, &zone->refill_counter);
-	if (atomic_read(&zone->refill_counter) > SWAP_CLUSTER_MAX) {
-		int count;
-
+	imbalance = zone->nr_active - (zone->nr_inactive*2);
+	if (imbalance <= 0)
+		imbalance = 1;
+	else {
 		/*
 		 * Don't try to bring down too many pages in one attempt.
 		 * If this fails, the caller will increase `priority' and
 		 * we'll try again, with an increased chance of reclaiming
 		 * mapped memory.
 		 */
-		count = atomic_read(&zone->refill_counter);
-		if (count > SWAP_CLUSTER_MAX * 4)
-			count = SWAP_CLUSTER_MAX * 4;
+
+		imbalance >>= priority;
+	}
+
+	atomic_add(imbalance, &zone->refill_counter);
+	nr_refill_inact = atomic_read(&zone->refill_counter);
+	if (nr_refill_inact > SWAP_CLUSTER_MAX) {
 		atomic_set(&zone->refill_counter, 0);
-		refill_inactive_zone(zone, count, ps, priority);
+		refill_inactive_zone(zone, nr_refill_inact, ps, priority);
 	}
-	return shrink_cache(nr_pages, zone, gfp_mask,
-				max_scan, nr_mapped);
+
+	return shrink_cache(nr_pages, zone, gfp_mask, max_scan, nr_mapped);
 }
 
 /*

_

  reply	other threads:[~2004-01-22  6:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-22  5:43 Nick Piggin
2004-01-22  6:36 ` Andrew Morton
2004-01-22  6:54   ` Nick Piggin [this message]
2004-01-22  7:04     ` Andrew Morton
2004-01-22  7:19       ` Nick Piggin
2004-01-22  8:16         ` William Lee Irwin III
2004-01-22 23:32           ` Nick Piggin
2004-01-22 10:35   ` Nikita Danilov
2004-01-22 23:01     ` Nick Piggin
2004-01-23 10:29       ` Nikita Danilov
2004-01-23 12:28         ` Nick Piggin
2004-01-23 15:09         ` Nick Piggin
2004-01-23 15:40           ` Nikita Danilov
2004-01-24  1:07             ` Nick Piggin
2004-01-26 11:19               ` Nikita Danilov
2004-01-26 11:25                 ` Nick Piggin
2004-01-26 12:14                   ` Nikita Danilov
2004-01-30  3:48                     ` Nick Piggin
2004-01-30  3:56                       ` Andrew Morton
2004-01-30 12:00                         ` Nikita Danilov
2004-01-23  7:16   ` Nick Piggin
2004-01-23  9:42     ` Nikita Danilov
2004-01-23 12:15       ` 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=400F738A.40505@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=Nikita@Namesys.COM \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    /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