89

What is better for performance? A partition closer to the inside of the disk will have slower access times, and we must wait for the drive to switch between the OS and swap partitions.

On the other hand, a swap partition bypasses all of the filesystem allowing writes to the disk directly, which can be faster than a file.

What is the performance trade off?

How much does having a fixed size swapfile make a difference?

Is it a case that it will be longer to change to the swap partition, but performance will be better while it is on the swap partition that if it had been a swap file?

Bill Gray
  • 1,295
  • 1
  • 11
  • 18

6 Answers6

50

  1. On hard disks, throughput and seeking is often faster towards the beginning of the disk, because that data is stored closer to the outer area of the disk, which has more sectors per cylinder. Thus, creating the swap at the beginning of the disk might improve performance.

  2. For a 2.6 Linux kernel, there is no performance difference between a swap partition and an unfragmented swap file. When a swap partition/file is enabled by swapon, the 2.6 kernel finds which disk blocks the swapfile is stored on, so that when it comes time to swap, it doesn't have to deal with the filesystem at all.

Thus, if the swapfile isn't fragmented, it's exactly as if there were a swap partition at its same location. Or put another way, you'd get identical performance if you used a swap partition raw, or formatted it with a filesystem and then created a swapfile that filled all space, since either way on that disk there is a contiguous region used for swapping, which the kernel uses directly.

So if one creates the swapfile when the filesystem is fresh (thus ensuring it's not fragmented and at the beginning of the volume), performance should be identical to having a swap partition just before the volume. Further, if one created the swapfile say in the middle of the volume, with files on either side, one might get better performance, since there's less seeking to swap.

On Linux, if the swapfile is created unfragmented, and never expanded, it cannot become fragmented, at least with normal filesystems like ext3/4. It will always use the same disk blocks, which are contiguous.

I conclude that about the only benefit of a dedicated swap partition is guaranteed unfragmentation when you need to expand it; if your swap will never be expanded, a file created on a fresh filesystem doesn't require an extra partition.

Shay
  • 501
  • 4
  • 2
  • 10
    The only thing to add here is that if you machine is configured to "suspend to disk" what is actually happening is that stuff in memory is written to swap. For this to work, the swap must be on it's own partition as the swap can't be on an active filesystem for this to happen. Therefore, if you have a server, you probably don't use this feature and could happily use a swap file. If you have a laptop, you probably do want a swap partition so you are able to "suspend to file" for hibernation. – Nathan S. Watson-Haigh Feb 17 '16 at 02:36
  • @NathanS.Watson-Haigh What happens with the data that's already in swap? It can't be thrown away. – XTF May 04 '17 at 09:57
  • 8
    @NathanS.Watson-Haigh Can you link a source? Ubuntu 17.04 uses a swap file by default. It would be surprising if it couldn't "suspend to disk". – Matthias Weiler May 18 '17 at 15:17
  • @MatthiasWeiler For what it's worth, I tested this on Debian 10 (Linux 4.19), and it didn't work; boot.log contains `resume: invalid resume device: /swap`. It could be an initrd limitation instead of a kernel limitation, but I didn't dig further. – marcelm Nov 20 '20 at 20:01
28

Actually it doesn't make a lot of difference as long as you don't use sparse files.

Creating a "normal" file with dd will allocate the file (if at all possible) in a single run, while creating a sparse file will tell you that you have a 10GB file lying around but not actually using up all the space. I'm not quite sure wether mkswap won't allocate the space anyway but typically a swap file will grow in time and thus won't allocate a continous sector (as in part of the disk) but rather allocate blocks as needed which lead to fragmentation over time (of course depending on your usage of the disk)

Internally the Linux kernel will access the underlying blocks of a swap file more or less directly - I can't find the link right now what happens under the hood, you have to trust me on this one unless someone will find something more official. All I can come up with right now is:

this all applies to the 2.6 line of Linux kernels only.

If you want optimal performance (and what is that, really?... swapping is slow, period. Increase RAM so that you don't swap for best performance), you would want to use a partition.

Martin M.
  • 6,428
  • 2
  • 24
  • 42
  • 22
    Modern versions of swapon will outright refuse to work with sparse files formatted as swap, citing that the file has holes. – Tim Post Apr 26 '11 at 02:30
3

This is an interesting question and have been reading a lot about the same. Generally a swap partition is better than a file due to the underlying filesystem. But if you are always in need to increase the size of your swap then file is a better option. Untill kernel 2.4 it was considered that a swap partition is faster than a file, but now with the improvements of kernel 2.6 , the performances are almost the same.

Something I found on internet as well.

http://www.go2linux.org/swap-file-vs-swap-partition

and

http://www.sunmanagers.org/pipermail/summaries/2005-November/006913.html

Viky
  • 638
  • 2
  • 7
  • 11
  • Neither of those links really explain the reasons behind their decisions however. – Bill Gray Jun 15 '09 at 03:47
  • The reasoning is that the file will have its underlying filesystem overload. If you create a file it could be fragmenged. and depending on the file which is being cached on swap, the reads could be slow as compared to an entire partition which is a swap file system in its own. – Viky Jun 15 '09 at 04:04
  • Tried to dig further and found relative article on wiki. Just to assist you there are few swap tuning parameters which you can check. Also check the explanation under implementation for linux. Might help. http://en.wikipedia.org/wiki/Paging – Viky Jun 15 '09 at 04:08
  • Followed one of the citations on the above mentioned wiki link and found an interesting thread about same issue. Might want to check that out. http://lkml.org/lkml/2005/6/28/427 – Viky Jun 15 '09 at 04:29
  • 1
    I mentioned the filesystem overload in my question, but it is not as much a performance block as having a partition near the inner disk is. That delay would be great than the filesystem overhead. – Bill Gray Jun 15 '09 at 05:00
3

The thinking at our work is that since a Swap file can become fragmented, and fragmentation slows swap access, a partition is a better approach. Of course, defining a staticly sized swapfile does much the same thing but this just seems subjectively neater.

Is this approach the one true way? Probably not, as the practice was established close to 10 years ago. The only major change in drive technology in the intervening years is the complexity of the RAID controllers we use (we're not rich enough for SSD's yet). The increase in drive sizes means that the swap partition we create is closer to the start of the drive than it was back when 18GB drives were shipping standard, so swap speeds are even faster than they were in olden days.

Of course, on our ESX-based Windows systems, position of the swap file is completely, completely moot. There are so many layers of virtualization between the swap file and the physical disk platters that it just doesn't matter. But we keep it on a separate partition because that's just the standard.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • 6
    A swap file does not become fragmented, as the kernel uses a direct mmap approach and will never grow or shrink the file. +1 though for your comment on virtualization: it often does not matter. – parasietje Mar 20 '14 at 18:13
2

I think at the stage we're at now, unless you're running a laptop with a configuration that writes the data to the swap when it suspends/sleeps, swap should really be considered "last resort". Your best bet is to put enough RAM in a box so that it never pages to disk.

That being said, a partition is probably the better way, performance wise, though a file is more flexible. Just make sure that it's on a 7200+ RPM spindle.

Matt Simmons
  • 20,218
  • 10
  • 67
  • 114
  • 1
    Why would a partition be better performance wise, when access times can be more of a factor for delay? – Bill Gray Jun 15 '09 at 03:23
  • 5
    Because using a file may require more head movements, because when finding the page to read/write the data could be anywhere on the filesystem so fs structures may need to be searched whereas with a swap partition each page will be in a known location within the partition. This makes access time (as apposed to bulk throughput) a differentiating factor. – David Spillett Jun 15 '09 at 07:26
  • 2
    "Don't configure swap unless you need to hibernate" is a controversial view. Sometimes when the system is low on real memory swap can allow the system to recover. Not having swap can limit you from running programs that make huge memory allocations but don't actually touch most of it (e.g. certain debugging tools). Sometimes an occupied but idle region of memory is better used as disk cache and that can that tradeoff can only be done if there's swap available. See https://unix.stackexchange.com/questions/2658/why-use-swap-when-there-is-more-than-enough-free-space-in-ram for discussion. – Anon Aug 08 '18 at 08:33
  • 2
    What @Anon said. Chrome is a notorious memory hog, and even with <100 tabs, my 16GB laptop becomes unresponsive for several minutes when memory utilization is around 90% and there's no swap file. Surprisingly, [Ubuntu has no built-in mechanism to warn the user that the OS is running out of memory](https://unix.stackexchange.com/a/289945/29324). – Dan Dascalescu Feb 13 '19 at 08:47
0

Using a swap file might use a bit extra memory for the file-to-memory-translation. We are talking about less than 1MB memory per 1GB swap. The file system cache does NOT cache swapped data, only the organisational data, which should be most of the extra memory requirements.

Besides that I doubt you will lose any reasonable performance except maybe once in a 1000 times a single additional head seek.

Funny fact, using zswap together with a dynamically expanding swap file results in an impressive speed up on swap operations at very little costs while unused.

Crass Spektakel
  • 1