On Jan 23, 2008, at 1:40 AM, Ron Johnson wrote:
Rick wroteOn my own systems, I make swap huge (10 GB or more for 1 GB RAM -- Diskis cheap!) so I can mount /tmp on a tmpfs filesystem.???? Is this for apps that say "if malloc() fails, I create a tmp file"? IOW, you pretty much ensure that malloc() will never fail?
That's one way of looking at it. It may be my old fashioned UNIX based superstitions, but I remember some benchmarks from ten years or more ago that showed putting /tmp on a tmpfs filesystem dramatically sped up things like compilers shell scripts and other programs that wrote small short-lived temporary files to communicate between passes.
If you have /tmp on physical disk (e.g. an ext3 filesystem) the process of opening a file for writing, writing it, closing it, re- opening it for reading, reading it back in, closing it and deleting it, hits the disk several times, even with a large buffer cache. But if that file is in a tmpfs filesystem and you've got enough ram, the disk never gets involved. If it's in a tmpfs filesystem but you don't have enough ram, you have to swap, but you're no worse off than you were with the disk-based filesystem.
Given that logic, and the fact that tmpfs is limited by the size of swap plus the size of ram, and the observation that disk is cheap and getting cheaper, why not make swap as big as you're ever likely to want?
Of course, now-a-days the gcc compiler does its thing entirely in core -- swap if you must but no temporary files ever. So the benchmarks may not apply.
I'm gettin' old... Rick