[systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl

[Uoti Urpala]

On Wed, 2014-07-16 at 20:22 +0200, Tollef Fog Heen wrote:
> ]] Lennart Poettering 
> 
> > (Also I see little point in /tmp not being a tmpfs anyway. If you want a
> > lot of space there, then use swap -- of which you can have up to 2G even
> > on 32bit systems. tmpfs on on swap has the great benefit that it
> > relieves the kernel from always having to utimately flush things to disk)
> 
> Swap doesn't scale well, though.  To the point where if the amount of
> swapped-out data is > 2x physical memory, kswapd starts gobbling CPU.
> 
> Yes, that's a bug that should be fixed, but it's been that way for years
> in Linux.

At least when I tested things a few years ago, tmpfs+swap seemed to have
a more significant performance problem than CPU use. Apparently the
kernel does not remember that the data is still on disk after it has
been read back to RAM; where a normal fs would simply drop disk-backed
data from RAM, tmpfs seems to do a new write each time. When the working
set is large, this means every read from tmpfs requires an equally big
write later.

I tested something like writing a file 2x RAM size to tmpfs and reading
it back several times. On a normal filesystem it's written to disk once
and then read 10 times. With tmpfs the reads generate both read and
write IO every time, and it's a lot slower.