On 06/21/2015 05:58 PM, Dan Ritter wrote:
On Sun, Jun 21, 2015 at 03:39:46PM -0400, Richard Pieri wrote:
When a process tries to allocate more pages than the total of clean
and unallocated pages in the page cache, well, that's an overload.
Overloaded system is overloaded. Game over. Install more RAM or
don't overload the system. If neither option is viable then put your
page file or partition on a fast SSD. That won't solve the problem
but it will make it seem less severe.
Remember that a lot of our expectations around VM and swapping
come from a time when a multiuser system might have 16 MB of
RAM. Hard disks transferred 25MB/s.
Suppose you had a 16MB system and allocated 16MB of disk for
swap. A request to evict a 4MB process and pull in another one
would take about 350ms -- not too bad.
Now let's say you have a 16GB system with 16GB of swap on disk,
and you want to evict a 4GB browser process and pull in another
one. Disk speeds went up to 100MB/s, so it only takes 80 seconds
or so! With a consumer SSD that gets lucky, you have a 500MB/s
transfer rate and can do it in 16 seconds, practically no time at
all. It's certainly less severe, but it isn't much fun.
Conclusion: swap is a last-ditch mechanism to save your system from
having to kill processes. The other two uses -- Linux trades out pages
that are likely to never be called again, or uses the swap space as
a sleep-time mechanism to store memory -- are still viable. It would
probably be best for a desktop machine that *is* going to be put to
sleep overnight to have a minimal amount of swap, and mount a larger,
pre-prepared swapspace for the purpose of sleeping. Unmount it
when awake.
Linux does not swap out pages that are not dirty. For instance code and
initialized data that has not been written to is never swapped out to
backing store. In the old days before virtual memory processes were
swapped in and swapped out. But today, VM is much more efficient.
Certainly if the system needs to free up memory, less recently used
pages may be swapped out to make room.
--
Jerry Feldman <[email protected]>
Boston Linux and Unix
PGP key id:B7F14F2F
PGP Key fingerprint: D937 A424 4836 E052 2E1B 8DC6 24D7 000F B7F1 4F2F
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
