BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] memory management
- Subject: [Discuss] memory management
- From: dsr at randomstring.org (Dan Ritter)
- Date: Sun, 21 Jun 2015 17:58:12 -0400
- In-reply-to: <55871302.1050705@gmail.com>
- References: <558420D5.6090803@mattgillen.net> <55870120.50605@gmail.com> <55871302.1050705@gmail.com>
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. -dsr-
- Follow-Ups:
- [Discuss] memory management
- From: gaf at blu.org (Jerry Feldman)
- [Discuss] memory management
- From: rlk at alum.mit.edu (Robert Krawitz)
- [Discuss] memory management
- References:
- [Discuss] memory management
- From: me at mattgillen.net (Matthew Gillen)
- [Discuss] memory management
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] memory management
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] memory management
- Prev by Date: [Discuss] memory management
- Next by Date: [Discuss] memory management
- Previous by thread: [Discuss] memory management
- Next by thread: [Discuss] memory management
- Index(es):