Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

Softpanorama University
Unix Installation Links

 

News

E-books

Selected Papers

Usenet

Recommended Sites

 Man Pages

Reference

Upgrades

HOW-TOs

Keyboard and Shell

Disks and partitioning

Swap partition

Net

Tech Support
Notes:
  • This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.
Google Search
Open directory
Research Index

News

Recommended Sites

In Russian

    Nexus NDG LINUX Page (in Russian)

E-books

Josh's Linux Guide -- contains several useful essays

  1. Configuring and Troubleshooting X
  2. Linux Commands
  3. Installing Software Packages
  4. Introduction
  5. Linux Basics and Tips
  6. Modifying Your Partitions and Help on LILO
  7. Using 'chmod'
  8. Using RPM

Linux Notes by

Linux Installation and operation

TCP/IP

Communications

Crypto and security

Other notes

HOW-TOs

Configuration

Upgrades

Ethernet

Setting Up Ethernet -- very good. The site Josh's Linux Guide contains other useful documents. Highly recommended.

Linux at CESDIS -- by Donald Becker

Ethernet HOWTO, by Paul Gortmaker <gpg109@rsphy1.anu.edu.au>. Information on Ethernet hardware compatibility for Linux. Updated 6 July 1998.

Linux NET-3-HOWTO

IP Masquerading mini-HOWTO

Kernel HOWTO, by Brian Ward <ward@blah.math.tu-graz.ac.at>. Upgrading and compiling the Linux kernel. Updated 26 May 1997.

Upgrades

Usenet

Disks and Partitioning

Three rules for successful repartitioning

Rule 1. Make a full backup of the disk or at least the most important files
Better to have a full backup and not need it than not have a backup and find you needed it. Please remember that files destroyed during repartitioning are very difficult to recover -- backup time is really tiny in comparison with efforts you will need in case something go wrong... 

Rule 2. Read the instructions
Partitioning isn't a crucial operation and errors are very costly. Do not try to do intuitively. Even if you've done it before, it pays to review the documentation. And if you've never done it before, or do it rarely, read those instructions closely.

Rule 3. Follow the instructions! Do not improvise during repartitioning

Swap partition

The Linux Documentation Project have some documents that give in depth description of swap space issues.

The Multi Disk HOWTO which is very much about tuning in general. It is way to big to quote here so I' rather suggest the interested readers look at the following chapters listed below (straight from the Multi Disk HOWTO homepage):

Note that the swap partiotn limit in old kernels depends on the architecture of the processor, namely if it is a 32- or 64-bits processor.

Ask SlashdotAsk Slashdot Linux and Swap Optimization

by MikeBabcock on Friday July 09, @12:52AM EDT (#79)
(User Info) http://www.linuxsupportline.com/~pgp/

If you have 128M of ram, for now, create two 64M (or 128M if you can spare the space, but I wouldn't) swap partitions on two different drives. If you have only one drive, make it a 128M partition near the beginning ...

Partitions:

/boot
SWAP
... others ...

... this way your kernel files are always in the first 1024 cylinders but your swap is at the fastest part of older disks (newer disks use scattering to make all reads and writes the same speed).

If you use two disks, and assuming the load on both is about the same, set the priorities to be equal in /etc/fstab:

/dev/hda2 swap swap defaults,pri=1 0 0
/dev/hdc2 swap swap defaults,pri=1 0 0

This way the Linux kernel automatically uses both partitions simultaneously for faster reads and writes. If your hard drive isn't doing anything else, you'll get twice the speed out of this.

Again, with 128M of ram, you only need 128M of swap, even for most mid-level server apps. If you want to run Slashdot on your PC, you might need more :) ...

... leave some unpartitioned space in the middle of your drive to add swap to later if you need to ... (or to quickly partition and back up data to if another partition craps out).
- Michael


Jim Frost

There's been a lot of talk about the old limits and why they were there and whatnot. Here's a little technical background as well as my own rules-of-thumb on size and location.

The old "2x" rule of thumb was always silly. What was important was that it was *at least* 1x. Why? Not because the kernel dumped core into the swap (which was true, but almost nobody really cared to grope through the dump so it was usually immaterial), but because every page of physical memory had a shadow page in swap. This was an important performance optimization.

First, realize that in most cases UNIX systems had only about half as much RAM as would be needed to hold everything running in RAM (even ignoring cache). 100% overcommit was *normal*; you just couldn't afford enough memory. On such systems swap performance could make or break a system.

BSD systems (and others) would start writing pages to swap long before memory space was exhausted, but keep the pages in memory as well. If the system suddenly needed more RAM to satisfy a request, any pages already written to disk could be grabbed immediately since they could be restored from swap later if necessary. If the application decided it needed the page before that happened, it was still there. Thus you could seriously overcommit memory without having much impact on performance.

Lots of people get worried about the performance impact of the (possibly) unnecessary page writes. I've never understood that; the way these systems work is you go tell the controller to do the write, then you go back to doing what you were doing and it'll let you know when it's done. Thus unless you're maxing out your controller/disk there is almost no penalty for doing it -- and it's a huge, huge win when you need RAM fast.

Some systems (notably Windows 95) don't start writing pages until they need more RAM. Doing this makes application performance synchronous with swap performance in overcommit situations -- and as we all know, that's going to suck royally. The upside to this approach is that the performance of the machine is maximized when everything *does* fit -- you're not doing any extra work -- and disk footprint of the system is minimized (a big deal when disks were a really big part of the cost of the whole system).

Assuming that what people here have been saying is true, that Linux swap space is additive, then my guess is that it uses a pool system such that it sets a low-water mark on free pages such that it starts shadowing pages when the low-water mark is exceeded. This management system goes under the assumption that there's some number of pages you might need immediately, but that's smaller than the total available page pool. That was usually true even in the old BSD days and is most definitely true today (what with everybody's desktop having 64MB or more, what luxury).

Anyway this approach provides the best of both worlds: if you have enough memory to keep the free page pool below the low-water limit then you don't do any extra work, but if you're running in a tight or overcommit mode you usually have a bunch of pages that you can steal fast if you need them. But beware the situation where total VM use exceeds real memory plus swap minus free page pool size -- you'll start swapping synchronously as the ability of the system to shadow pages disappears.

My rule of thumb, now as always, is to set swap such that the total VM space is roughly twice what I think I'll ever need in day-to-day operations, but at least as large as RAM.

Why that big? Because sometimes you blow right through your typical VM usage and it's better to have the machine respond slowly than to have things fail. Now that disk is cheap there's not much reason not to just pick a pretty big number.

As for why make it as large as RAM, well, call it superstition. Quite a number of VM systems on the market today (most particularly Windows NT) perform quite poorly if you don't have at least as much swap as RAM, and some even limit available RAM to the size of swap if you do that (as BSD used to do). Since I don't always have the time (or sometimes even the documentation) to figure out which ones use which policy I just pick a number large enough that it can't ever be a problem.

Now, about swap location. Ideally you have a whole disk dedicated to swap, but these days disks are so large that you couldn't realistically make use of a whole disk (or even a tenth of one) for swap unless you're working with some really serious datasets.

So pretty much everyone splits up their disk.

So far in replies I've heard recommendations for putting the swap at the low cylinders, middle, and high. There are two things you trade off in position -- data transfer rate and head movement.

If you put the swap at the outside or inside of the disk you're going to be moving the heads a long way any time you need to swap a page, assuming that one or another filesystems on the disk is in regular use (typically the case). On the outside, however, you may get some of that back because data transfer rates are the highest. Putting it on the inside (low cylinder numbers) is idiotic -- they have the slowest transfer rates *and* you usually have to move the heads a lot. Modern disks are so fast that this isn't really much of a problem, but it's so easy to avoid that there's no reason to do it.

I suggest putting it somewhere in the middle, preferably between your two most active partitions. Since the swap partition is usually relatively small compared to filesystems you don't make seek time that much longer between filesystems, and you ensure that you're pretty close to the swap partition all the time.

Lastly, we've heard comments that claiming both that swapping to a file is slower than swapping to a partition, and that that's not true. It *is* true. Large files (eg a swap file) will be fragmented somewhat, forcing additional disk/head movement in some cases, and you'll also have to deal with metadata describing where on the disk the file blocks are. This eats up both in-system filesystem cache and causes additional disk activity while you load metadata that's not in the cache.

Swapping to a file is something I'd do in an emergency or if you need more swap and can't justify repartitioning or adding a new disk. If you can plan ahead of time you should avoid it, it will always be somewhat slower, although realistically speaking with today's systems you might not be able to tell.

(I feel like an old fogey. You wouldn't believe how cool I think it is that I can have pretty much as much memory and disk as I want. Why, when I was a young hacker, we had to swap our programs to paper using a pencil....)

Keyboard and Shell

See also:

Net

Home Server with Linux - document that explains how to share a modem and printer with a Windows 95 machine 

 

 

 

How-TOs

Hardware

X installation and configuration

Other Useful mini-HOWTOs

The following mini-HOWTOs are available:

Technical Support

Cyrillication

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: November 13, 2004