Using TMPFS for /tmp and /var/run?
jb
jb.1234abcd at gmail.com
Sun Apr 1 19:55:13 UTC 2012
Rainer Duffner <rainer <at> ultra-secure.de> writes:
>
> Am Sun, 1 Apr 2012 09:40:25 -0400
> schrieb Gary Palmer <gpalmer <at> freebsd.org>:
>
> > Other than catching software that mistakenly assumes /tmp
> > and/or /var/run is persistent, what are the CLEAR advantages for
> > changing the default?
>
> It's my understanding it improves performance in cases where lots of
> files are created and deleted in /tmp (and/or /var/tmp - sometimes
> software hard-codes these locations...).
> ...
> OTOH, on new installs, a TMPFS could be used automatically if memory >=
> 4GB.
> ...
There are memory management subsystem considerations against utilizing
tmpfs (memory + swap) for /tmp:
- only part of the program needs to be in the memory for execution
Delayed and hidden demand for memory.
- demand paging
Bring a page from swap into memory only when it is needed.
Delayed and hidden demand for memory.
- Copy-on-Write
Initial sharing of memory by processes.
Delayed and hidden demand for memory.
- thrashing
Excessive in/out swap utilization.
Very high page-fault rate -> low CPU utilization -> OS thinks it can schedule
more tasks -> another process added for execution
- memory overcommit
Physical memory overcommit resulting in paging; swap space pre-reservation
Due to it, on heavy loaded systems processes dying on memory pressure.
- Out-of-Memory (OOM) killer
Due to it, on heavy loaded systems processes dying on memory pressure.
There is a potential for overlapping and multiplying effects from the above and
possibly other factors.
If somebody wants it, despite all dangers to efficiency and stability of their
system, let them make that choice. After all, what real pros are known for is
that they know why and how to customize their systems for a task.
To offer it as a default setup is not called for, regardless of memory plus
swap sizes.
jb
More information about the freebsd-current
mailing list