Re: Linux 2.1 wishlist...

Stephen C. Tweedie (sct@dcs.ed.ac.uk)
Sun, 16 Jun 1996 13:57:37 +0100


Hi again,

On Sat, 15 Jun 1996 12:23:03 -0500 (CDT), mcastle@umr.edu (Mike
Castle) said:

> Amazingly enough Stephen C. Tweedie said:
>> There IS one area where knowing the underlying device can be genuinely
>> useful, though. If we are paging from binaries on an NFS mounted
>> partition, then it can be helpful to swap those binaries to a local
>> fast disk rather than to keep paging them from the network. This

> Actually, I'd like to see this as an option for ALL filesystems,
> not just NFS. I'm not convinced that always rereading a page
> from the original binary is faster than paging out to a dedicated
> swap partition. Less seeks, more potential use of clustering,
> etc. I believe OS/2 switched from always paging from binaries to
> moving the code to swaparea, and had a performance increase as a
> result (someone correct me if I'm wrong). Yes, you suddenly need
> more swap space, but I think it would be faster.

Sometimes, it might be. However, this feature really has nothing to
do with the underlying paging filesystem, so it would automatically be
available as a per-mount option for all filesystems.

A proven way to improve the performance of any system under swapping
load is to keep your binaries and swap on separate disk drives. That
way, the kernel can be doing paging and swapping simultaneously. Try
it --- you might be surprised at what a difference it can make. In
this case, it is a bad mistake to page binaries onto a swap device.
You end up losing much of the advantage of having two devices to page
from.

In any case, writing text pages to swap incurs an extra write, so your
paging device would have to be awfully slow (or heavily loaded for
other things) before this would improve performance. Of course, NFS
_is_ awfully slow for random access, which is why I'd be looking at
this primarily as an aid for networked systems, not a way to improve
the swapping performance on local disks.

Cheers,
Stephen.

--
Stephen Tweedie <sct@dcs.ed.ac.uk>
Department of Computer Science, Edinburgh University, Scotland.