On Sun, Nov 26, 2006 at 04:37:35PM +0100, Petter Reinholdtsen wrote: > [Roger Leigh] > > tiny amount, like the 100 KiB suggested. For /dev/shm, requirements > > could be a lot higher, and vary from system to system, but again a > > sensible default would fix this. > Why should /dev/shm/ be so high? There are almost no application > using the shm*() functions in glibc. Which one of these need a large > file?
Well, afaik database systems use lots of shared memory. I don't know if they use POSIX shared memory, though. > > The current practice of using the kernel default of 0.5*coresize is > > wrong. I'm currently safe, having a good 6 GiB of swap, but for high > > memory systems with less swap than core, you're heading into potential Well, don't call it "safe", one can easily trigger the OOM-killer if there is no currently-able-to-swap memory out there. And making tmpfs buffers unable-to-swap is simple by just touching the data frequent enough. > I believed unused tmpfs space wasn't taking up any space in the > kernel. Is this not so? I don't know if the fixed space needed for meta-data increases with the maximum size of a tmpfs. > Well, it is not obvious to me that the various tmpfs file systems do > have widely different size requirements, so I do not plan to deprecate > it myself. Well, *if* you have a system that uses lots of POSIX shared memory, you would probably like to have a chance to define the sizes quite different. Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle
signature.asc
Description: Digital signature