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 --]
prev parent 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