Am Donnerstag, 29. März 2012 schrieb Javier Vasquez: > So yes, one needs to be careful, not to oversize your tmpfs. That's > completely true, but the limit is not physical RAM, it is actually > RAM+Swap, as I mentioned before. > > On this thread, it is asked about how to got with huge files to be > handled by tmpfs, well, debian still gives the option to set /tmp as a > regular partition for example, but if you also have enough swap space, > then by setting the right tmpfs size, you can still get away with it > through tmpfs. Actually in this case I suggested 2g or even 3g for > tmpfs, which was discarded because it sounded dangerous at first by > looking only at RAM, and not considering at all the available swap, > which in my mind and experience is a mistake.
Only thing with this could be that swapping in my observation has a quite high I/O priority. When I have my students in my Linux performance analysis & tuning trainings test to allocate lots of memory, more than physical RAM the Linux machine responds quite jerky and I get much higher latencies. Thus when I access something from a tmpfs that it is swap I might have higher latency for my usual workloads. And it might even be faster to just read it from disk. But then everything from the tmpfs that is in physical RAM is accessed way faster as from disk as well. I.e. I let the kernel decide and autotune for my workload. IMHO it might be better to size / use tmpfs in a way that only uses swap rarely or seldom. But your mileage may vary. Or it might be wise to reduce the priority of swapping for tmpfs filesystem, but I am not sure whether that would be feasible to implement to the kernel. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201204042033.44628.mar...@lichtvoll.de
