Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 04 Nov 2012 09:46:40 -0700
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org
Subject:   Re: watchdogd, jemalloc, and mlockall
Message-ID:  <1352047600.1120.148.camel@revolution.hippie.lan>
In-Reply-To: <2D77347F-9913-4727-AA57-204AC266E15C@bsdimp.com>
References:  <1351967919.1120.102.camel@revolution.hippie.lan> <20121103184143.GC73505@kib.kiev.ua> <1351968635.1120.110.camel@revolution.hippie.lan> <2D77347F-9913-4727-AA57-204AC266E15C@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2012-11-04 at 09:36 -0700, Warner Losh wrote:
> On Nov 3, 2012, at 12:50 PM, Ian Lepore wrote:
> 
> > On Sat, 2012-11-03 at 20:41 +0200, Konstantin Belousov wrote:
> >> On Sat, Nov 03, 2012 at 12:38:39PM -0600, Ian Lepore wrote:
> >>> In an attempt to un-hijack the thread about memory usage increase
> >>> between 6.4 and 9.x, I'm starting a new thread here related to my recent
> >>> discovery that watchdogd uses a lot more memory since it began using
> >>> mlockall(2).
> >>> 
> >>> I tried statically linking watchdogd and it made a small difference in
> >>> RSS, presumably because it doesn't wire down all of libc and libm.
> >>> 
> >>> VSZ   RSS
> >>> 10236 10164  Dynamic
> >>> 8624  8636  Static
> >>> 
> >>> Those numbers are from ps -u on an arm platform.  I just updated the PR
> >>> (bin/173332) with some procstat -v output comparing with/without
> >>> mlockall().
> >>> 
> >>> It appears that the bulk of the new RSS bloat comes from jemalloc
> >>> allocating vmspace in 8MB chunks.  With mlockall(MCL_FUTURE) in effect
> >>> that leads to wiring 8MB to satisfy what probably amounts to a few
> >>> hundred bytes of malloc'd memory.
> >>> 
> >>> It would probably also be a good idea to remove the floating point from
> >>> watchdogd to avoid wiring all of libm.  The floating point is used just
> >>> to turn the timeout-in-seconds into a power-of-two-nanoseconds value.
> >>> There's probably a reasonably efficient way to do that without calling
> >>> log(), considering that it only happens once at program startup.
> >> 
> >> No, I propose to add a switch to turn on/off the mlockall() call.
> >> I have no opinion on the default value of the suggested switch.
> > 
> > In a patch I submitted along with the PR, I added code to query the
> > vm.swap_enabled sysctl and only call mlockall() when swapping is
> > enabled.  
> > 
> > Nobody yet has said anything about what seems to me to be the real
> > problem here:  jemalloc grabs 8MB at a time even if you only need to
> > malloc a few bytes, and there appears to be no way to control that
> > behavior.  Or maybe there's a knob in there that didn't jump out at me
> > on a quick glance through the header files.
> 
> Isn't that only for non-production builds?
> 
> Warner

I don't think so, I discovered this on my tflex unit running -current,
and it's built with MALLOC_PRODUCTION defined because it doesn't have
enough ram to boot without it defined.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1352047600.1120.148.camel>