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

Re: Moving /tmp to tmpfs makes it useless


Now lets do a benchmark on a busy system (during a kernel compile) and 
some memory pressure, due to building on tmpfs. While this is not 
directly representative for /tmp/ usage patterns, it does show what 
happens if /tmp/ gets full and fights against normal RAM uses.

Tested on a current unstable system under KDE 4.7.4, debuild invoked 
under 'konsole'. For each test the system was freshly rebooted and is
mostly idle. As an indicator for system responsiveness the only 
application running besides konsole && debuild is kaffeine, displaying 
a 720*576 DVB-T/ MPEG2 stream.

*system specifications*
- Intel Core2 Quad Q9550, 2.8 GHz
- 8 GB RAM
- ATI RV630 [Radeon HD 2600 Series]
  using xserver-xorg-radeon and its firmware
- Seagate ST31000340AS HDD, 1 TB, 7200 rpm
- io scheduler cfq registered (default)
- kernel 3.4.1-rc1

required space for building linux-2.6 3.2.19-1 on amd64 using debuild 
on an unclean host, involving a lengthy lintian run (no devscripts.conf
customisation), ~19 GB

single GPT partition spanning the whole disk, freshly formatted with 
ext4 (all defaults, empty).
/dev/sdc1 /mnt ext4 rw,relatime,data=ordered 0 0

[during the build, towards the end (docbook generation)]
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7991       7830        160          0         57       6435
-/+ buffers/cache:       1338       6652
Swap:            0          0          0

$ time debuild -j8
real    142m17.038s
user    249m31.896s
sys     33m25.303s

The system remains responsive during the whole build time, video 
display remains fluent.

single GPT partition spanning the whole disk, freshly mkswap'ed
benchmark /mnt tmpfs rw,nosuid,nodev,relatime,size=838860800k 0 0

[during the build, towards the end (docbook generation)]
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7991       7486        504          0          2       6527
-/+ buffers/cache:        956       7034
Swap:       953868       7142     946726

[immediately after the build]
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7991       7250        740          0         87       6302
-/+ buffers/cache:        861       7129
Swap:       953868      11846     942021

$ time debuild -j8
real    163m15.803s
user    253m6.583s
sys     35m38.599s

Once the system gets under memory pressure (more than ~7-9 GB space 
needed on tmpfs), system responsiveness is gone. Video playback becomes
a strobe light slide show, mouse and cli are choppy, moving windows is 
basically impossible - not enough to get tempted to hit hard-reset, but
interactive system use is no longer useful.

Of course this is not a representative benchmark, unless swap is
many times larger than system RAM, but it shows what happens when
tmpfs gets full (which is not an unlikely situation, as demonstrated 
in this thread) and enforces swapping. Keep in mind that the OOM killer
cannot evict tmpfs, but only page it out. However comparable 
situations might easily arise on systems up to 1 GB RAM and twice its 
RAM size as swap, these systems have basically no RAM to spare for 

While I'm not arguing for or against the RAMTMP defaults, given that I 
tend deviate from normal procedures[1] here, I don't think systems with
less than 2 GB system RAM can spare any of their RAM for /tmp/[2]. Even
on systems with more RAM, it might be pretty hard to reserve enough space
on a tmpfs backed /tmp/ to meet the expectations of contemporary 
applications, without compromising on system memory.

	Stefan Lippers-Hollmann

[1]	by bind mounting /var/tmp/ on /tmp/, either backed by a
	separate /var/ partition or a dedicated /var/tmp/ partition on
[2]	using KDE4 or GNOME3, anything below 1 GB RAM severely limits
	"multi-tasking"; running browser, office suite, PDF viewer, 
	file manager at email client at once basically requires 
	~1.5 GB RAM at least.

Reply to: