Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] memory management



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-



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org