[lkml]   [2001]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[TINY patch] VM compromise?
Hi Rik,

Thoughts on the below?

real 9m50.322s
user 7m7.810s
sys 0m36.020s

2.4.2.ac11+limit kswap expectations and scan slightly heavier
real 8m23.122s
user 7m8.860s
sys 0m33.960s

At no time do I see cache collapse as in earlier kernels, nor do I see
cache bloat as in virgin ac >= 3. I think this is a good compromise
candidate. This is almost as good as my best by fiddling with I/O..
[8m3s] _without_ fiddling with I/O, and it only changes 2 lines instead
of nuking a large chunk of your [damn difficult] balancing work :)

Why do I think it works?

1. kswapd attempting to fix everything in one run doesn't take
into account that tasks not only allocate, they also free. If
we try to fix everything, we're usually assuring an overreaction.

2. scanning a little more agressively brings the cache shrinkage
to swap ratio to something more realistic for this work load..
and I strongly suspect many others as well.

--- linux-2.4.2.ac11/mm/ Sun Mar 4 17:28:54 2001
+++ linux-2.4.2.ac11/mm/vmscan.c Sun Mar 4 17:15:23 2001
@@ -847,7 +847,7 @@
* continue with its real work sooner. It also helps balancing when we
* have multiple processes in try_to_free_pages simultaneously.
-#define DEF_PRIORITY (6)
+#define DEF_PRIORITY (4)
static int refill_inactive(unsigned int gfp_mask, int user)
int count, start_count, maxtry;
@@ -858,7 +858,7 @@
maxtry = 6;
} else {
/* kswapd */
- count = inactive_shortage() + free_shortage();
+ count = (inactive_shortage() + free_shortage()) >> 2;
maxtry = 1 << DEF_PRIORITY;

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.037 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site