Date: Thu, 23 Aug 2012 15:54:20 -0600 From: Warner Losh <imp@bsdimp.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: alc@freebsd.org, current@freebsd.org, Alan Cox <alc@rice.edu> Subject: Re: less aggressive contigmalloc ? Message-ID: <DF42DC8C-C971-48CB-8257-A964B47A446A@bsdimp.com> In-Reply-To: <20120823174504.GB4820@onelab2.iet.unipi.it> References: <20120822120105.GA63763@onelab2.iet.unipi.it> <CAJUyCcPOte19TJXpCVAskhf%2BDia_Zg5uj6J_idW67rGsOLaZXw@mail.gmail.com> <20120823163145.GA3999@onelab2.iet.unipi.it> <50366398.2070700@rice.edu> <20120823174504.GB4820@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 23, 2012, at 11:45 AM, Luigi Rizzo wrote: > On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote: > ... >>> yes i do see that. >>>=20 >>> Maybe less aggressive with M_NOWAIT but still kills processes. >>=20 >> Are you compiling world with MALLOC_PRODUCTION? The latest version = of=20 >=20 > whatever the default is. But: The default is OFF, so jemalloc uses oodles and oodles more memory than = before. On any system less than 256MB that I've tried to boot on lately = I've had to define MALLOC_PRODUCTION (which, btw, should be named = WITH_MALLOC_DEBUG instead to conform to our naming scheme for options, = but I digress). With MALLOC_PRODUCTION defined, I boot on 32MB systems = with about 8MB of RAM to spare when I get to the login prompt. Warner >> jemalloc uses significantly more memory when debugging options are=20 >> enabled. This first came up in a thread titled "10-CURRENT and swap=20= >> usage" back in June. >>=20 >> Even at its most aggressive, M_WAITOK, contigmalloc() does not = directly=20 >> kill processes. If process death coincides with the use of=20 >> contigmalloc(), then it is simply the result of earlier, successful=20= >> contigmalloc() calls, or for that matter any other physical memory=20 >> allocation calls, having depleted the pool of free pages to the point=20= >> that the page daemon runs and invokes vm_pageout_oom(). >=20 > does it mean that those previous allocations relied on memory = overbooking ? > Is there a way to avoid that, then ? >=20 > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DF42DC8C-C971-48CB-8257-A964B47A446A>