ideal number of swap partitions and sizes (slightly different from other posts)

[Timothy A. Seufert]

At 10:13 AM -0500 4/24/02, Ryan Mesler wrote:
>i noticed about a year and a half ago that linux supports multiple swap
>drives. since then i've always made a minimum of two swap partitions (using
>the ext2 filesystem).
>
>i've noticed somewhat better performance when doing this on low end
>machines. but then again, i always had a doubt that it was probably wishful
>thinking and that possibly the performance gains i noticed were imaginary.

There is a performance gain if and only if the swap partitions are on 
different drives.  The Linux kernel does the equivalent of RAID 0 
when you give it multiple swap partitions / files to play with.

If the partitions are on the same drive, you are probably reducing 
performance rather than increasing it.

>does anyone actually know for sure if there is indeed a performance gain.
>
>also, take a look at this scenario: 64mb physical ram
>
>one swap drive of 128 mb, or two swap drives of 64.
>
>which would be more beneficial for the system. what if i were to make one
>giant swap drive (like 1gb) rather than 4 smaller ones (256mb each). can
>anyone enlighten me? i've read many howto's but none have addressed these
>questions and unfortunately, most of the linux users in newsgroups...
>well... they're less than kind.

The size of swap does not affect performance in and of itself.  It 
only determines how much memory the system can allocate and use 
before running out; i.e. if you have 64MB RAM + 64MB swap there is a 
total of 128MB of memory available for the operating system to 
allocate. (*)  It is very doubtful that you will ever need 1GB of 
swap -- and if you did you'd want to get that much RAM instead.

* This is complicated by the fact that Linux uses overcommit 
semantics for memory allocation -- programs can actually ask for more 
memory than is available, and be told that they got it.  Many 
programs never use all the memory they allocate; through virtual 
memory tricks it's possible to not *really* allocate memory until the 
program actually touches it.
-- 
Tim Seufert