From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:24:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7BB9FA3; Sat, 3 Nov 2012 18:24:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 644F28FC0C; Sat, 3 Nov 2012 18:24:16 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qA3IODlt018632; Sat, 3 Nov 2012 20:24:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qA3IODAU018631; Sat, 3 Nov 2012 20:24:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Nov 2012 20:24:12 +0200 From: Konstantin Belousov To: alc@freebsd.org Subject: Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?.. Message-ID: <20121103182412.GB73505@kib.kiev.ua> References: <20121030175138.GA73505@kib.kiev.ua> <20121031140630.GE73505@kib.kiev.ua> <20121031172136.GB21003@dan.emsphone.com> <1351707655.1120.94.camel@revolution.hippie.lan> <20121031190623.GL73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+cTHE2B7cPyeMCYH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:24:16 -0000 --+cTHE2B7cPyeMCYH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 03, 2012 at 01:11:17PM -0500, Alan Cox wrote: > On Wed, Oct 31, 2012 at 2:06 PM, Konstantin Belousov wrote: >=20 > > On Wed, Oct 31, 2012 at 11:52:06AM -0700, Adrian Chadd wrote: > > > On 31 October 2012 11:20, Ian Lepore > > wrote: > > > > I think there are some things we should be investigating about the > > > > growth of memory usage. I just noticed this: > > > > > > > > Freebsd 6.2 on an arm processor: > > > > > > > > 369 root 1 8 -88 1752K 748K nanslp 3:00 0.00% watchdogd > > > > > > > > Freebsd 10.0 on the same system: > > > > > > > > 367 root 1 -52 r0 10232K 10160K nanslp 10:04 0.00% watchdogd > > > > > > > > The 10.0 system is built with MALLOC_PRODUCTION (without that defin= ed > > > > the system won't even boot, it only has 64MB of ram). That's a cra= zy > > > > amount of growth for a relatively simple daemon. > > > > > > Would you please, _please_ do some digging into this? > > > > > > It's quite possible there's something in the libraries that are > > > allocating some memory upon first call invocation - yes, that's > > > jemalloc, but it could also be other things like stdio. > > > > > > We really, really need to fix this userland bloat; it's terribly > > > ridiculous at this point. There's no reason a watchdog daemon should > > > take 10megabytes of RAM. > > Watchdogd was recently changed to mlock its memory. This is the cause > > of the RSS increase. > > > > > Is it also statically linked? No. I do not think that it is reasonable to statically link watchdogd. It might result in some memory saving, but I dislike the whole idea of static linkage on Tier 1 platforms. --+cTHE2B7cPyeMCYH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCVYUwACgkQC3+MBN1Mb4ihBgCgmllKOe59qY5KhOr3TWIhuwRo ZSsAnjxN5zeep8omSq4UiTrw8tV13Zea =oYuq -----END PGP SIGNATURE----- --+cTHE2B7cPyeMCYH--