On 2003-07-23 18:52 -0700, Don Lewis <[EMAIL PROTECTED]> wrote: > On 23 Jul, Brooks Davis wrote: > > On Thu, Jul 24, 2003 at 12:36:54AM +0200, Matthias Buelow wrote: > >> Barney Wolff writes: > >> > >> >One might argue that this is a config error, and ulimit should be used > >> >to cut the address space to below actually available memory. > >> > >> Wasn't there a sysctl flag to enable/disable overcommitting? > >> I think I remember something but I can't find it; it might > >> not have been on FreeBSD. > > > > No there isn't. Overcommit is a fundamental design feature of the BSD > > VM. If you don't like it, find an OS that doesn't do it. The only one > > I can think of off the top of my head in Irix where I've found it to be > > a serious pain in the ass. > > I think it's a pain in the ass when swap runs out and the kernel decides > to kill off my X11 server to fix the problem. In addition to losing > everything I'm working on, it also hoses the console. The only reason > that I can avoid having to hit the reset switch and risking further > system damage is that I have another machine that I can ssh in from to > do a clean shutdown.
Hmmm, might it be possible to have an upper limit on the amount of available memory (RAM+SWAP) used, before malloc() fails for non-root processes ? (A little bit like the "reserved" space in FFS, though I know that you can't directly compare the two.) Think about having a sysctl variable that is set to the amount of RAM (in KB, MB or %VM) that should be free for further calls to malloc() to succeed. Programs that need more heap space after this limit is crossed, will receive NULL as a result and can take appropriate measures. The limit is VM *used* (not *allocated*) against total VM, so this does not imply that memory overcommit should be abandoned. Programs that touch malloced space immediately, will see some percent less available VM, but that is cheap today (even a 64MB Soekris box might be able to cut off some 1 or 2MB, I guess). This does not protect against malicous code that on purpose allocates lots of heap space, but only touches it, when overcommit of this one program extends avalaible VM. But there are other places where it is hard to protect against malicious users and you can already enforce resource limits for users. The proposed implementation would just take a single sysctl (initially set to 0, so no difference to now) and brk/sbrk would check allocation request for non-root processes against available VM space. Forking of non-root processes might be restricted as well, if the VM use limit is exceeded ... Any comments ? Regards, STefan _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
