From owner-freebsd-embedded@FreeBSD.ORG Sun Nov 4 16:47:05 2012 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E96BF8A; Sun, 4 Nov 2012 16:47:05 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C39668FC08; Sun, 4 Nov 2012 16:47:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qA4Gl3Cc075619; Sun, 4 Nov 2012 09:47:03 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qA4GkeLN011274; Sun, 4 Nov 2012 09:46:40 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: watchdogd, jemalloc, and mlockall From: Ian Lepore To: Warner Losh 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> Content-Type: text/plain; charset="us-ascii" Date: Sun, 04 Nov 2012 09:46:40 -0700 Message-ID: <1352047600.1120.148.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 16:47:05 -0000 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