autoregulation needed

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

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

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

Index: linux-2.6.7-bk20/mm/vmscan.c
===================================================================
@@ -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