Hi Rik,
Thoughts on the below?
2.4.2.ac11-virgin
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/vmscan.c.org 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
