How Linux actually uses swap space?

Okay, I am a bit befuddled here...

Almost everything I have heard about Linux, including stuff garnered from the LKML and KernelTrap, indicates that it pages unused stuff out of RAM rather aggressively to make room for filesystem cache (assuming a swap partition is present). IOW, swap lets Linux make better use of physical RAM - and you can have stuff in it even when low RAM is not forcing the kernel to swap.

That's all well and good, except that in my experience:

- I've yet to see any Linux system perform worse without swap space; in fact, most perform better without it. If swap gave Linux more room for FS cache, I'd expect to see some improvement with a swap partition when not in low RAM conditions.

- zram doesn't produce any performance improvement until the kernel is forced to swap, i.e. it increases the the threshold of performance loss but doesn't improve things when memory isn't being hogged. Again, if Linux used swap preemptively, I'd expect to see a performance improvement when giving it an extra ~512 MB of very fast swap space.

- Most damningly: when I formatted an SD card as swap, and enabled it as the sole swap device, iostat reported no reads or writes on the device whatsoever. None. At all. Only when I created a low RAM situation did reads and writes start to occur (along with thrashing and performance loss).

So I'm left wondering if all the stuff I've read about why I need a swap partition is actually dead wrong. Does iostat not track all I/O operations related to paging? Is it not so easy to tell when the kernel is paging out inactive stuff? Or is the "common wisdom" about swap incorrect?

 

I can't answer all your questions. But you might experiment with the swappiness setting. You can find out your current setting with

sysctl vm.swappiness

You can change that value to, say, 20 by executing

sudo sysctl vm.swappiness=20

Values between 0 and 100 can be used. 0 means that file cache is only used if RAM is full.

In order to make that value permanent you have to add

vm.swappiness=20

to /etc/sysctl.conf.

Some people recommend to keep swappiness values small if you have plenty of RAM so you should experiment according to your needs. Swap usage can be observed with swapon -s.

 

Thanks, but I've already confirmed that lower swappiness always means better desktop performance, at least as far as I can tell - even when the kernel is being forced to swap. In fact, that's when it makes the most difference.

I'm more curious at this point about whether Linux pages stuff out preemptively, and whether I can keep track of when it does that. This seems to be a place where some serious Linux geeks hang out, so I figured I'd get an answer here sooner or later.

 

I noticed an improvement in Xubuntu.
https://www.wilderssecurity.com/showpost.php?p=1998692&postcount=11

 

Swap is the same on Windows as it is on Linux. When the system is running low on RAM it pages it to make room for more. On Linux you can adjust the swapiness to change the threshold before it pages.

If you have 4GB of RAM and 2GB free, 1GB cached, 1GB in use, and your system starts paging you're wasting some free RAM.

I just removed my swap partition. I don't see any reason to use it.

And zcache is for people with not a lot of RAM/ really slow hdd.

 

Ocky: Thanks, but that's not my question. I already know what settings improve performance on Linux. What I want to know is how Linux manages paging. Does it page out inactive memory aggressively? Or does it not even touch swap space until it reaches the threshold set by swappiness?

The issue is that the LKML crowd says it pages aggressively, while iostat and my own eyes say it doesn't page at all until it hits the swappiness threshold. So either iostat is somehow wrong, or a bunch of people on the LKML don't know what they're talking about.

 

Thank you, that was the information I was looking for. Can't say I'm surprised, hard disks are several orders of magnitude slower than RAM.

I'm a bit curious about the Windows side of things BTW. Is the non-RAM part of "commit charge" occupied swap space? Virtual memory, including the full size of the running binaries? Or is Task Manager just lying?