public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	FabF <fabian.frederick@skynet.be>,
	lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH] Autotune inactivation
Date: Sat, 10 Jul 2004 22:30:33 +1000	[thread overview]
Message-ID: <40EFE169.5060304@kolivas.org> (raw)
In-Reply-To: <40EFDA89.4020001@yahoo.com.au>


[-- Attachment #1.1: Type: text/plain, Size: 1922 bytes --]

Nick Piggin wrote:
> FabF wrote:
>> http://fabian.unixtech.be/kernel/autoregulate/

> I didn't see Con's newest autoswappiness patch do a great deal
> for kbuild here. The inactivation thing seems to help more - it
> appears to increase the rate of active list scanning, which is
> consistient with the sort of behaviour I have seen. However, the
> problem with increased active list scanning is that it can be
> quicker to evict RSS over throwaway data which is bad.
> 
> Changes should be tested one at a time if possible, and when they
> are determined to be an improvement, we should try to look into
> what the "auto tuning" magic is doing right, and see if that can
> be implemented in a simpler way (although it may be already as
> simple as possible).

The autotuned swappiness part tended to have the most effect at avoiding 
the morning drag, or the post ISO image copy drag without slowing things 
down under real heavy memory stress.

The original version of autotuned inactivation simply increased the 
number of pages scanned and had better results on my benching but this 
part of code changed somewhat and I dont think I put it back to the best 
way. This patch recreates more closely the behaviour of the original 
version.

It would be nice if people who have tested the previous more confused 
patches to try these two in sequence and see what measurable results 
they give.


Description:
This patch increases the number of active pages inactivated and the 
number of inactive pages freed dependent inversely on the vm_swappiness. 
The vm_swappiness in turn is tuned by the previous patch 
(autotune_swappiness) according to the mapped ratio. As the 
vm_swappiness is proportional to the square root of the mapped ratio, 
this means that the mapped ratio has to be quite high before this patch 
has any great effect.

Patch applies to 2.6.7-bk20 and mm6
Signed-off-by: Con Kolivas <kernel@kolivas.org>

[-- Attachment #1.2: autotune_inactivation.diff --]
[-- Type: text/x-patch, Size: 1015 bytes --]

Index: linux-2.6.7-bk20/mm/vmscan.c
===================================================================
--- linux-2.6.7-bk20.orig/mm/vmscan.c	2004-07-10 20:10:25.324562938 +1000
+++ linux-2.6.7-bk20/mm/vmscan.c	2004-07-10 21:17:08.045968091 +1000
@@ -801,20 +801,23 @@
 {
 	unsigned long nr_active;
 	unsigned long nr_inactive;
+	unsigned long mapped_bias;
+
+	mapped_bias = 151 - vm_swappiness;
 
 	/*
 	 * Add one to `nr_to_scan' just to make sure that the kernel will
 	 * slowly sift through the active list.
 	 */
 	zone->nr_scan_active += (zone->nr_active >> sc->priority) + 1;
-	nr_active = zone->nr_scan_active;
+	nr_active = zone->nr_scan_active * 150 / mapped_bias;
 	if (nr_active >= SWAP_CLUSTER_MAX)
 		zone->nr_scan_active = 0;
 	else
 		nr_active = 0;
 
 	zone->nr_scan_inactive += (zone->nr_inactive >> sc->priority) + 1;
-	nr_inactive = zone->nr_scan_inactive;
+	nr_inactive = zone->nr_scan_inactive * 150 / mapped_bias;
 	if (nr_inactive >= SWAP_CLUSTER_MAX)
 		zone->nr_scan_inactive = 0;
 	else

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

      reply	other threads:[~2004-07-10 12:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-10  9:50 autoregulation needed FabF
2004-07-10 12:01 ` Nick Piggin
2004-07-10 12:30   ` Con Kolivas [this message]

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=40EFE169.5060304@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=fabian.frederick@skynet.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.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