Date: Fri, 04 Jan 2008 21:08:12 +0600 From: "Vadim Goncharov" <vadimnuclight@tpu.ru> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: sbrk(2), OOM-killer and malloc() overcommit Message-ID: <opt4euzyj44fjv08@nuclight.avtf.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opt4euzyj44fjv08>