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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
