[HEADS-UP] Rawhide: /tmp is now on tmpfs

[Gregory Maxwell]

On Fri, Jun 1, 2012 at 11:27 AM, Gerry Reno <greno at verizon.net> wrote:
> Wait a minute.  Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp.
> Plus the purported benefit from this is causing less write cycles on SSD.  (See Wiki page)
> That may have been a benefit a few years ago but newer SSD's will gain almost nothing from this because of the enormous
> number of write cycles they handle.

You're not understanding the word "allocate" in the same way it
actually behaves.  It does not reserve memory. The default maximum
size (think of it as a quota) of a tmpfs mount is half whatever amount
of actual ram you have. You can expand or shrink a tmpfs mount using
the size= mount option.

Memory is not actually used until things are stored there, and if the
result is memory pressure the kernel will intelligently page out the
least used pages. (e.g. tmp files that haven't been accessed in a long
time, or inactive application memory instead of an actively accessed
file on tmp), per the normal vm policy.

Because that disk activity only happens when the kernel decides that
it wants the memory for something else it doesn't happen at all in a
great many cases especially for short lived files.

> This "feature" may have some benefits but I think they are infinitesimally small.

The feature may be adopted/promoted on the basis of SSD writecycle
preservation, but tmpfs also offers considerable performance
improvements for workloads that create/remove files in /tmp at high
speed— which is the reason that many people have been using tmpfs for
/tmp on many systems for much longer than SSDs have existed.