From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 30 20:08:10 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 780DE1065673; Mon, 30 Jul 2012 20:08:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 331918FC17; Mon, 30 Jul 2012 20:08:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7F4B1B962; Mon, 30 Jul 2012 16:08:09 -0400 (EDT) From: John Baldwin To: freebsd-embedded@freebsd.org Date: Mon, 30 Jul 2012 14:22:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120726143551.b2b0ce30.ray@freebsd.org> <20120730113418.97694fdf.ray@freebsd.org> In-Reply-To: <20120730113418.97694fdf.ray@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207301422.10029.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jul 2012 16:08:09 -0400 (EDT) Cc: Aleksandr Rybalko , jasone@freebsd.org Subject: Re: jemalloc vs old allocator X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:08:10 -0000 On Monday, July 30, 2012 4:34:18 am Aleksandr Rybalko wrote: > On Fri, 27 Jul 2012 10:04:27 -0700 > Adrian Chadd wrote: > > >> Just as a note, ray@ compared jemalloc-HEAD with an older jemalloc. > >> > >> I've just asked him to compare it to phkmalloc from -8. He'll > >> hopefully post those results soon. > >> > >> Still, great work. :) > >> > >> > >> > >> Adrian > >> > >> > >> On 26 July 2012 04:35, Aleksandr Rybalko wrote: > >> > Hi, > >> > > >> > I believe what Jason Evans done many test before commit jemalloc, > >> > but made by myself simple test for embedded environment. And get > >> > following results: > >> > > >> > 1. old malloc: > >> > Sum of RSS of userland programs: 28544K > >> > > >> > sysctl vm.vmtotal: > >> > System wide totals computed every five seconds: (values in > >> > kilobytes) =============================================== > >> > Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: > >> > 19) Virtual Memory: (Total: 2372224K Active: 250316K) > >> > Real Memory: (Total: 18096K Active: 11392K) > >> > Shared Virtual Memory: (Total: 15824K Active: 5288K) > >> > Shared Real Memory: (Total: 2644K Active: 2408K) > >> > Free Memory: 2192K > >> > > >> > > >> > 2. jemalloc with MALLOC_PRODUCTION: > >> > Sum of RSS of userland programs: 21196K > >> > > >> > sysctl vm.vmtotal: > >> > System wide totals computed every five seconds: (values in > >> > kilobytes) =============================================== > >> > Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: > >> > 19) Virtual Memory: (Total: 2380988K Active: 257820K) > >> > Real Memory: (Total: 19048K Active: 12144K) > >> > Shared Virtual Memory: (Total: 16180K Active: 5392K) > >> > Shared Real Memory: (Total: 2664K Active: 2392K) > >> > Free Memory: 2440K > >> > > >> > I check it on DIR-632(Atheros AR7242 with 32M RAM) between 10-20 > >> > mins of uptime. Device behave identical in both cases. > >> > > >> > So if "something" new take more memory than before, that > >> > "something" is not a jemalloc :) > >> > > >> > P.S. Many thanks to Jason for such great job! > >> > > >> > WBW > >> > -- > >> > Aleksandr Rybalko > > Hi all, > > so, unlike both jemallocs, Poul's version of malloc born with more free > memory: > > Sum of RSS of userland programs: 25444K > > sysctl vm.vmtotal: > System wide totals computed every five seconds: (values in kilobytes) > =============================================== > Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 19) > Virtual Memory: (Total: 2163524K Active: 59196K) > Real Memory: (Total: 16656K Active: 10144K) > Shared Virtual Memory: (Total: 5620K Active: 5200K) > Shared Real Memory: (Total: 2552K Active: 2356K) > Free Memory: 3140K > > But after half a day with some minor activity (logs on tmpfs, racoon > connect attempts, etc.) free memory goes down to: > > Free Memory: 2316K > > and continue get more and more memory, after full day, it is around > 1.5M free. It is ok to have "low" free memory. The kernel will just keep file data cached around forever if it can. When free memory hits a certain target, then the pagedaemon process will wake up and shuffle some inactive pages down to "cache" to free up more memory. However, until that happens cached file data will just stay in "inactive" and the kernel will keep using "free" pages. -- John Baldwin