autoregulation needed

autoregulation needed

[FabF]

Hi,

	I've been surprised these last days to read ar wasn't that interesting
(!!!) so I did a slight bench :

http://fabian.unixtech.be/kernel/autoregulate/

Well, I hope we can have that pretty stuff in mainline.I'm bored
patching it again and again.

If some persons could confirm GUI is relaxed with autoregulation (well
its my case but I could use a box from Mars or smthg :) ).

Thanks,
FabF

Re: autoregulation needed

[Nick Piggin]

FabF wrote:
> Hi,
> 
> 	I've been surprised these last days to read ar wasn't that interesting
> (!!!) so I did a slight bench :
> 
> http://fabian.unixtech.be/kernel/autoregulate/
> 
> Well, I hope we can have that pretty stuff in mainline.I'm bored
> patching it again and again.
> 
> If some persons could confirm GUI is relaxed with autoregulation (well
> its my case but I could use a box from Mars or smthg :) ).
> 

That is a good start.

I don't think we need to rush in changes here on the basis that
they improve a *really* thrashing workload, although obviously
that is interesting, and a definitely positive point.

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).

[PATCH] Autotune inactivation

[Con Kolivas]

[-- 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 --]