Peter Humphrey wrote:
On Wednesday 08 July 2009 14:51:04 Frank Peters wrote:
Or is the system designed to extend the tmpfs through swapping?
Sort of. If the tmpfs becomes full, part of it that isn't needed at the
moment is swapped to disk, exactly as if it had been program space.
This is not completely accurate. The size limit you set on the tmpfs is
the size of the filesystem. df will show that many bytes free, and if
you write one byte more you'll get an error that the filesystem is full.
Completely independent from this, the kernel will swap memory out to
disk when needed. If I have 300GB of RAM, and a 1GB tmpfs, and 5GB of
resident programs, most likely nothing will be swapped up until the time
the tmpfs is full. At that point the tmpfs will report that it is full,
and still nothing will have swapped (most likely - the kernel can still
swap stuff out in favor of cache even if the RAM is 99.999% unutilized).
If I have 2GB of RAM and 10GB of tmpfs, then the system is guaranteed
to swap long before that tmpfs fills up.
In general, the guideline is to set your tmpfs up to be big enough to
handle a large emerge (such as openoffice/firefox) - at least a few GB.
Be sure to have enough swap space to handle the size of your full
tmpfs + anything you're likely to be running - amount of physical RAM.
If you run out of swap before you run out of tmpfs space, then the
next write to the tmpfs is going to trigger the OOM killer. I'm not
sure how tmpfs is prioritized by the OOM killer, but suffice it to say
you're either going to lose tmpfs data or running processes. If you
can't make your swap big enough, then you could set a smaller tmpfs and
then just unmount it before emerging large programs. Note that more
than just portage ends up in /var/tmp - I'm not sure what kde does if
its cache disappears mid-session.
Again, unless you're running in unusual circumstances I don't think you
need to worry about the number of tmpfs inodes.
