Date: Thu, 22 Jul 2010 10:59:14 -0700 From: mdf@FreeBSD.org To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: Multi-zone malloc(9) Message-ID: <AANLkTimHrUAlJbWA5gfLDA4oozpfnon4LCZBiCRFuFla@mail.gmail.com> In-Reply-To: <20100722174120.GR2381@deviant.kiev.zoral.com.ua> References: <AANLkTikoY8CuAF3DThBAXH_mu1QAuUWyRMtkaIomaoi7@mail.gmail.com> <20100722174120.GR2381@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 22, 2010 at 10:41 AM, Kostik Belousov <kostikbel@gmail.com> wro= te: > On Thu, Jul 22, 2010 at 09:54:51AM -0700, mdf@freebsd.org wrote: >> Occasionally we run into use-after-free and malloc'd buffer overrun >> scenarios. =A0When this happens it can be rather difficult to determine >> what code is at fault, since e.g. every 64 byte allocation, regardless >> of malloc type, comes from the same UMA zone. =A0This means that an >> overflow in M_TEMP will affect M_DEVBUF, etc. =A0Adding multiple uma >> zones for each bucket size means that we can hash on the malloc type's >> shortdesc field so that there are fewer collisions and misused memory >> from one malloc type only affects a subset of other malloc types. >> Varying the hash means that, with several crashes due to memory stomp, >> a single malloc type can usually be determined as the culprit. =A0If the >> bug isn't obvious from inspection at this point, MemGuard will help >> catch the offender. >> >> The patch at: >> >> =A0 =A0http://people.freebsd.org/~mdf/multizone_malloc.patch >> >> implements an optional multi-zone malloc(9). =A0By default there is a >> single zone, and MALLOC_DEBUG_MAXZONES can be specified in the kernel >> configuration file. =A0A ddb function will print all the malloc types >> that have a hash collision with the specified type. >> >> A few questions for -arch@: >> >> =A0- We found this very useful at Isilon. =A0Should this go into CURRENT= ? >> >> =A0- Should this be on by default for GENERIC? =A0The memory overhead of= 8 >> uma zones per malloc allocation size shouldn't be very large. >> >> =A0- would a __FreeBSD_version bump be needed since the malloc_internal >> type is known by user-space? > > Can you quantify the overhead, both in CPU time and memory usage terms > ? I would much prefer to have debug and non-debug kernels to run > similar code, in other words, can the multizone allocation be enabled > unconditionally ? CPU usage should be lost in the noise, since the subzone hash class is computed once at boot. Memory overhead is a bit hard to quantify, since with multiple zones there are more partially allocated pages in each malloc size. Worst case would be, I think, 1 page per CPU per multi-zone per allocation size, so for 4 CPUs with 4k pages, that would be 4*8*9 or a little over 1MB. The actual number of multi-zones is also a TUNABLE, so the same code could be built for debug and non-debug, and a loader.conf change would enable the actual use of multiple zones during boot. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimHrUAlJbWA5gfLDA4oozpfnon4LCZBiCRFuFla>