I tried you patches (included below) on a 2.1.131 kernel and there
was a noticable improvement under heavy load. I have a C++ application
that has many source and include files, and that uses templates
extensively. The virtual image of the EGCS compiler grows to 70 to
80 MB on some files and my PC only has 64MB of RAM.
I 'time'd the compilation of this application using vanilla 2.1.131:
610.510u 75.660s 24:49.75 46.0% 0+0k 0+0io 167009pf+235932w
Then I applied your patches, rebuilt, rebooted, and repeated the test:
631.650u 74.920s 24:24.99 48.2% 0+0k 0+0io 164174pf+261103w
The compile time improvement (about 1.7%) is OK _and_ there was also
a noticable improvement in the 'feel' of the system if I run X and
emacs while compiling. Without your patch, interactive response times
from emacs were often several seconds long.
FYI, I have two swap areas (64MB each) on two disks so I don't know
which of your changes the largest contributor to the performance
improvement.
Thanks!
Ben McCann
Rik van Riel wrote:
>
> On Wed, 2 Dec 1998, Linus Torvalds wrote:
>
> > 2.1.131 is out there now - and will be the last kernel release for a
> > while. I'm going to Finland for a week and a half, and will be back
> > mid December. During that time I hope people will beat on this.
>
> There are a few things in the VM balancing of 2.1.131 that
> I strongly disagree with and that will make performance
> far worse than it could have been.
>
> +++ linux/mm/swap.c Fri Nov 27 10:15:29 1998
> - 25, /* borrow percent buffer */
> + 10, /* borrow percent buffer */
> - 30, /* borrow percent page cache */
> + 15, /* borrow percent page cache */
>
> Decreasing the borrow percentages will make the system
> clear out the caches too soon. The system should basically
> be self-tuning and the borrow percentages are only there
> to make sure that the system doesn't continue swapping
> when we have obscene amounts of cache.
>
> +++ linux/mm/vmscan.c Mon Nov 30 16:05:40 1998
> @@ -431,7 +431,7 @@
> kmem_cache_reap(gfp_mask);
>
> if (buffer_over_borrow() || pgcache_over_borrow())
> - shrink_mmap(i, gfp_mask);
> + state = 0;
>
> This is a good fix as it returns behaviour back to the normal
> and desired behaviour (except for too heavy cache pruning).
> This patch would have been better however, since it does what
> we want without too heavy cache pruning or massive swapout
> frenzies.
>
> +++ ./mm/vmscan.c Tue Dec 1 07:12:28 1998
> @@ -431,6 +431,8 @@
> kmem_cache_reap(gfp_mask);
>
> if (buffer_over_borrow() || pgcache_over_borrow())
> + state = 0;
> + if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster / 2)
> shrink_mmap(i, gfp_mask);
>
> switch (state) {
>
> This patch (against 2.1.130) makes sure that kswapd will free
> memory even during heavy swapout frenzies. This makes sure
> that kswapd will finish (swapout frenzies don't free memory
> and make kswapd swap too much without doing it's job) without
> swapping too heavily.
>
> By testing for swap_cluster/2 we make sure that we don't hamper
> swapout throughput too much and don't block the I/O subsystem
> either.
>
> I have been using this patch for several days now without any
> problems whatsoever (and far better performance than ever before).
>
> And finally here is a third patchlet to fix page_io.c, it should
> be fairly obvious what this patch does. It is mainly useful when
> we have multiple swap partitions over which we stripe -- increasing
> the value of swap_cluster will give us much more throughput then.
>
> --- ./mm/page_io.c.orig Thu Nov 26 11:26:49 1998
> +++ ./mm/page_io.c Thu Nov 26 11:30:43 1998
> @@ -60,7 +60,7 @@
> }
>
> /* Don't allow too many pending pages in flight.. */
> - if (atomic_read(&nr_async_pages) > SWAP_CLUSTER_MAX)
> + if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster)
> wait = 1;
>
> p = &swap_info[type];
>
> regards,
>
> Rik -- the flu hits, the flu hits, the flu hits -- MORE
> +-------------------------------------------------------------------+
> | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
> | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
> +-------------------------------------------------------------------+
>
> -
> 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/
--
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmccann@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111
-
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/