From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 4 14:16:46 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 0DD1FA23 for ; Sun, 4 Nov 2012 14:16:46 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87D138FC14 for ; Sun, 4 Nov 2012 14:16:44 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1955814bkc.13 for ; Sun, 04 Nov 2012 06:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ttD06boqS71E7uTQCsAS6v/wyAP3kpl4rTX0ZuA+m/A=; b=e8J9GT2dIkegiLUS4BJfkaVtGN9TgEJrw90QL8lR/wPGEEgdyFlm48iFmMQwUxUsfG Sp6uoTN9JiPq1GkeuuPRN15IizQsZaEaSCwihHOa4knW7GGqQvdaNxgAPWXDu16U8lwB 73AQVXSPWv+H6cIyyi6fYw5Nefj0zaYBqjHmk2hOifi1m7T6DSWxaJaMRbD8ax+w+aCn co7lFw/QQJ2QIMDHR7i7MgcrBAva7oTnr5RniP3QSm7jd17xdhg5z8x68FGTzNYEtWNG yWIOQPXLI/MfOp7PvqikHKSSB2xCcfrLctXCVqa1DFTkFZUarblNvCnKBatUlQ+dwSp5 t0Mg== MIME-Version: 1.0 Received: by 10.204.131.87 with SMTP id w23mr1675588bks.73.1352038603561; Sun, 04 Nov 2012 06:16:43 -0800 (PST) Sender: heliocentric@gmail.com Received: by 10.204.227.135 with HTTP; Sun, 4 Nov 2012 06:16:43 -0800 (PST) In-Reply-To: <1351973531.1120.118.camel@revolution.hippie.lan> References: <1351967919.1120.102.camel@revolution.hippie.lan> <50957793.8060709@delphij.net> <1351973531.1120.118.camel@revolution.hippie.lan> Date: Sun, 4 Nov 2012 09:16:43 -0500 X-Google-Sender-Auth: a3DRJB4l8tfv4fw3x5hOCsvgtNc Message-ID: Subject: Re: watchdogd, jemalloc, and mlockall From: Dylan Cochran To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 04 Nov 2012 14:16:46 -0000 Have you already tried something like opt.lg_chunk? This, combined with other options for the library (man 3 jemalloc), should reduce the space from 8MB down to 16K, or so. (approximation, I'm being liberal for jemalloc's internal bookkeeping size). For a special case like watchdogd, this would make more sense in general (given it should be designed to do no allocations/deletions during normal operation anyway). For other programs, this would be as unwise as statically linking them. The 'perfect' solution would obviously be improving the library manager (rtld) to only mmap() function pages it needs, though I will admit I'm not sure if the ELF format is even capable of supporting something like that, what other problems it would cause down the road, or if it even attempts to do this already (I haven't looked at the runtime linker code since 7.0). By the way, remember that when you compare static v dynamic, that the runtime linker does allocate private memory to handle the resolving of symbols to virtual memory addresses. That may skew your memory usage figures a bit. On Sat, Nov 3, 2012 at 4:12 PM, Ian Lepore wrote: > > On Sat, 2012-11-03 at 12:59 -0700, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On 11/3/12 11:38 AM, 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. > > > > Speaking for this, the last time I brought this up, someone (can't > > remember, I think it was phk@) argued that the shared library would > > use only one copy of memory, while statically linked ones would be > > duplicated and thus use more memory. I haven't yet tried to prove or > > challenge that, though. > > That sounds right to me... if 3 or 4 daemons were to eventually be > statically linked because of mlockall(), then each of them would have > its own private copy of strlen(), and malloc(), and so on; we'd be back > to the bad old days before shared libs came along. Each program would > contain its own copy of only the routines from the library that it uses, > not the entire library in each program. > > On the other hand, if even one daemon linked with shared libc uses > mlockall(), then all of libc gets wired. As I understand it, only one > physical copy of libc would exist in memory, still shared by almost all > running apps. The entire contents of the library would continuously > occupy physical memory, even the parts that no apps are using. > > It's hard to know how to weigh the various tradeoffs. I suspect there's > no one correct answer. > > -- Ian > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"