sbrk(2), OOM-killer and malloc() overcommit

[Vadim Goncharov]

Hi,

There were talks in 'sbrk(2) broken' thread about memory hogs which can  
easily eat all available VM despite of resources. That'smust be fixed or  
it will make a bad reputation  for FreeBSD as a server platform. But there  
are related "bug", in that of malloc overcommit, which can be demonstrated  
by this short program (if no resource limits are present, you'll see):

#include <unistd.h>
/* http://alter.tomsk.ru/bugs/head/ */
/* (C) Vladimir */
/* alter at alter tom ru */
int main(int argc, char **argv){
#define MB 1048576
const size_t step = MB;
size_t size = (size_t) 4095 * MB;
char *p;
printf("%s $Rev: 54 $\n", argv[0]);
printf("start size = %u MiB, step = %uMiB\n", size / MB, step / MB);
for(;size;){
	p = (char *)malloc(size);
	if(p){
		printf("allocated %u MiB\n", size / MB);
		puts("calling bzero()...");
		puts("NEXT MESSAGE SHOULD BE \"*** OK ***\", ELSE - THERE IS BUG IN A  
KERNEL");
		bzero(p, size);
		puts("*** OK *** Seems this OS doesn't contain the bug!");
		return(0);
		}
	else	{
		size -= step;
		}
	}
return(0);
}

There are people with long-running data-mining big processes that blame  
FreeBSD for being "not serious for serious server tasks" due to this bug,  
because other systems allow for some kind of memory reserving from  
additional files or other overcommit tuning (Linux has overcommit  
probability reducing tunable, which is enough for most such tasks). I know  
there exists a patch (which was again mentioned in thread),  
http://people.freebsd.org/~kib/overcommit/index.html - but it has never  
gone into src tree. So why we still have this problem, why not have at  
least this patch?..

-- 
WBR, Vadim Goncharov