ehlo. > : Second, application not always grows to 1G, most of the time it keeps > : as small as 500M ;). Why should we precommit 1G for 500M data? Doing > : multi-mmap memory management is additional pain. > > Why not? Disk space is cheap.
Developer time is expensive. Someone already wrote good allocation routines, and they are inside libc. Reinventing bycicle in every new large-scale application doesn't sounds good for me. > For a problem like this I would simply > throw in two 30G+ hard drives and partition them with 16G of swap each, > giving me 32G of swap for the machine. As it was said here before, there are actually two problems: notification (avoiding silently kills) and getting more paging space. The second can be solved by adding swap space. The first -- cannot. As developer, I'm more interested in first. Current solution with killproc() is not acceptable. Just imagine any OS documentation which say: "the OS may terminate process at any point with no warning or notification". Would you like to use it? But this is exactly what FreeBSD does at OOM. > Even using file-backed memory is fairly trivial. You don't need to > do multi-mmap memory management or do any kernel tweaking. Just > reserve 1G and use a single mmap() and file per process. As I already said, it is not trivial. It involves writing/adopting some allocation stuff. It means time & human resources -> money. -- dozen @ home To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
