[Discuss] memory management

[rlk at alum.mit.edu (Robert Krawitz)]

On Sun, 21 Jun 2015 17:58:12 -0400, 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.

That would have been early-mid 1990's -- disk throughput at that time
for IDE drives was maybe 2 MB/sec.  SCSI drives might have been a bit
faster, and with command queuing, could optimize head seeks.  But
throughput wasn't the problem; latency (and I/O rate) was the real
issue.

> 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. 

And as you note below, swapping is only an emergency mechanism.
Swapping is a lot more efficient than paging, since it has some hope
of using close to the full bandwidth of the disk, but at 2 MB/sec, the
overhead is significant.  The problem with swapping is that it greatly
reduces responsiveness; the process is completely evicted from memory
and has to be brought back in, and something else removed by paging or
swapping, so you're going to have a lot of latency (possibly many
seconds).

> 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.

I've certainly seen my laptop thrash (at least before I added an SSD
and put the swap partition on it), but I think it's paging rather than
swapping that usually did me in.  With swapping, processes will stall
entirely for extended periods of time, but with paging, they'll keep
running, pulling in pages as needed.  From an SSD, even a cheap
consumer-grade mSATA, that isn't too painful; 50K IO/sec of even 4K
pages isn't too bad unless access patterns are really awful (the
process will take under 100 usec to pull a page in).  If your process
can keep running without needing another page for 1 msec, the impact
won't be bad at all.  With a spinning drive that might top out around
200 IO/sec, it's another story; it will take more like 5 msec.  Then
you're really taking a hit.

System startup (particularly window system startup after boot) behaves
very much like a system in thrash; a lot of processes are kicking off,
competing against each other for the bandwidth and IOPS needed to pull
in enough program text to get to the point where they're executing out
of RAM rather than constantly pulling stuff off disk a page or few at
a time.

(I know about the recommendation not to put swap on an SSD because
you'll shorten its lifetime.  Personally, I think that's bollocks.
Consumer-grade SSD's have a lifetime around 500 TB of writes; unless
you're chronically severely memory-starved it will take ages for you
to get there.  SSD's are great for small random accesses; demand
paging of anonymous pages is done with small random accesses.  Pretty
good match.)

> 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.

What it really boils down to is that you need enough memory for your
worst case working set, or you're going to get unhappy awfully fast.
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton