[LUAU] Running a standard distro without swap space

[Jim Thompson]

On May 13, 2005, at 10:41 AM, Charles Lockhart wrote:

> Jim, Angela, Vince, Wayne, thanks!
>
> Yeah, I knew about the embedded linux - no swap partition thing.  I 
> use several that don't have (can't have) swap space, everything is 
> running out of RAM.  I just wasn't sure if the desktop distros 
> possibly tied stuff up differently somehow.

some of my embedded distros run a live filesystem, so they're not 
completely "running from RAM".  the executables/shared libraries are 
demand-paged from the (JFFS2) filesystem (which also involves a 
decompression step).  Its mostly fine and dandy.

> So I did as Vince recommended, and setup up a box to not use the swap 
> space.  Works fine, mostly.  After a while I started adding processes, 
> eventually exceeded physical memory, and then everything got 
> reeeeaaaaalllllllyyyyy ssssslllllllloooooooowwwwww.

I was going to write and post the canonic "stress your VM" programs.   
its fairly trivial to (m)alloc up a lot of memory (as much as the 
system will let you have) and then loop through this memory space, 
touching one byte on each page, but it seemed silly.

(you can make it worse and loop backwards such that the VM's "read 
ahead" policy is wasted)

> But no processes were being killed off, and I could still start more.  
> This confused me.  I checked around, found references indicating that 
> when both physical memory and swap space are full, the mm can start to 
> drop executable code from memory, as this can be refreshed from the 
> binary on the regular filesystem.  That's the only culprit I could 
> figure out, unless the system is building up some swap file unknown to 
> me.

yep, they're just (relatively) cold copy-on-write pages, and its 
unlikely that you have many processes scribbling on the in-ram image of 
the executable (at least the text segment) or shared libraries.

Further, some of the page usage will be for the buffer cache, and this 
can also get thrown out under heavy demand.   These pages also (of 
necessity) have a backing store.

The VM system is fairly careful to account for all allocations, so 
killing processes due to a lack
of swap is pretty rare these days.

> I think the real answer for the instrument is to add more ram and run 
> fewer processes.  The balance of contention between reading data from 
> one pci bus and then writing processed data over another pci bus to 
> disk is delicate at higher speeds anyway.  When the mm starts dumping 
> less used stuff to disk, the extra io kills the balance.  Or at least 
> that's my thinking.

If you've got the ability to add more ram, then, yes, typically ram is 
cheap.