>>> It would also be nice to not have two separate mm cycles (one that
>>> grow the cache until borrow percentage and the other one that shrink
>>> and that reach very near the limit of the working set). We should
>>> have always the same level of cache in the system if the mm stress
>>> is constant. This could be easily done by a state++ inside
>>> do_try_to_free_pages() after some (how many??) susccesfully returns.
>>
>>I'm seeing a pretty stable cache behaviour here, on everything from
>>4MB to 64MB systems.
>
>It works fine but it' s not stable at all. The cache here goes from
This patch should rebalance the swapping/mmap-shrinking (and seems to
works here, even if really my kswapd start when the buf/cache are over max
and stop when they are under borrow, I don' t remeber without look at the
code what the stock kswapd is doing):
Index: vmscan.c
===================================================================
RCS file: /var/cvs/linux/mm/vmscan.c,v
retrieving revision 1.1.1.1.2.16
diff -u -r1.1.1.1.2.16 vmscan.c
--- vmscan.c 1998/12/12 12:31:57 1.1.1.1.2.16
+++ linux/mm/vmscan.c 1998/12/12 14:27:55
@@ -439,7 +439,8 @@
kmem_cache_reap(gfp_mask);
if (buffer_over_borrow() || pgcache_over_borrow())
- state = 0;
+ if (shrink_mmap(i, gfp_mask))
+ return 1;
if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster / 2)
shrink_mmap(i, gfp_mask);
The patch basically avoids the clobbering of state so the mm remains
always in state = `swapout' but the cache remains close to the borrow
percentage. I should have do that from time 0 instead of using state =
0...
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/