From owner-freebsd-hackers@freebsd.org Thu Nov 10 22:01:04 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2730C3B068 for ; Thu, 10 Nov 2016 22:01:04 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84198BC2 for ; Thu, 10 Nov 2016 22:01:04 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-49bff70000007435-97-5824ecea06de Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 64.21.29749.AECE4285; Thu, 10 Nov 2016 16:55:55 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id uAALtrlT017015; Thu, 10 Nov 2016 16:55:53 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAALtn4b018419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2016 16:55:52 -0500 Date: Thu, 10 Nov 2016 15:55:50 -0600 From: Benjamin Kaduk To: Matthias Andree Cc: freebsd-hackers@FreeBSD.org, Mark Linimon Subject: Re: sbrk(0) replacement for memory resource tracking? (was: [linimon@FreeBSD.org: svn commit: r425823 - in head: benchmarks/stress-ng cad/cider cad/ngspice_rework databases/mariadb100-server databases/mariadb101-server databases/mariadb55-server databases/virtuoso devel/ace deve...]) Message-ID: <20161110215549.GL91607@kduck.kaduk.org> References: <20161110012624.GA23701@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixG6novv6jUqEwZ4NahbbN/9jtLi1fimr Rfv7OWwOzB4zPs1n8fjwMc6jafcDxgDmKC6blNSczLLUIn27BK6MdXdeMRdc5q04dLedpYHx AlcXIyeHhICJxNd5y1m7GLk4hATamCSu3L7ACJIQEtjIKHH3CQdE4iqTRPv5LcwgCRYBVYl3 D44zgdhsAioSDd2XweIiAjoST7bMBLOZBVwkGm5fYwdpFhZYyyTx524TO0iCF2hd7+bpTBAb EiWWzVzNBhEXlDg58wkLRLOWxI1/L4FqOIBsaYnl/zhATE4BK4n3p4tBKkQFlCUaZjxgnsAo MAtJ8ywkzbMQmhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQICltOSd4d jP/ueh1iFOBgVOLhlehUiRBiTSwrrsw9xCjJwaQkyqs4HSjEl5SfUpmRWJwRX1Sak1p8iFGC g1lJhNfzFVCONyWxsiq1KB8mJc3BoiTO+9/ta7iQQHpiSWp2ampBahFMVoaDQ0mC9/lroEbB otT01Iq0zJwShDQTByfIcB6g4QdAaniLCxJzizPTIfKnGBWlxHnZQRICIImM0jy4XlBakcje X/OKURzoFWFed2CSEeIBpiS47ldAg5mABs+IAxtckoiQkmpgnGm0anbNgumdKgUtvB6njxzL UvvV+a+B++DTmcEZlwvv5IeEvtnSFHkk5dw5ocl+IpbvygNLpiwy03/peHLCEZOOtFX+ip9/ OXyfvGz5O7ePrxv73jEk/l/xVSqLIW+XYNCCtRGB7F5rtatvlU0yWW3LkumSW1ejICX8YtJq JrvJDkzr7voeVWIpzkg01GIuKk4EADQesgUGAwAA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 22:01:04 -0000 On Thu, Nov 10, 2016 at 10:21:18PM +0100, Matthias Andree wrote: > Am 10.11.2016 um 02:26 schrieb Mark Linimon: > > FYI. Unfortunately I do not know what the generic fix is yet. But at > > least this will prevent the package builders from wasting time right now. > > > > I will try to keep the following page updated as I learn more: > > > > https://wiki.freebsd.org/PortsBrokenWithSbrk > > > > (oops, I forgot I have not put in the proper logfile URLs yet. Let me > > get started on that.) > > > > mcl > > Please help me understand the issue, and if by adding one or two > introductory paragraphs to the Wiki. Looks like r300303 is the relevant one for aarch64 (RISC-V got a similar treatment later?). > To me it looks like the sbrk() function is going away from our base > system underneath a stable 11-* branch. If that is true, I'll have to > object to that and request sbrk() be put back, we add a deprecation > notice now (if necessary via errata notice) and pull it only from FreeBSD12. At the time I somehow convinced myself that it had never been in a stable release and was thus okay, but maybe I'm misremembering. Hmm, or maybe it is okay for a tier-2 architecture [in the mind of the committer, not necessarly me, to be clear]. > OTOH, e2fsprogs uses only sbrk(0) to track its overall memory use, and > only to track its resource usage. I'll be happy to help porting to Same for zephyr. > something else that serves the same purpose, aka "how much memory am I > using" - but what would that be? I think there isn't really a drop-in replacement. N.B. that the number from sbrk(0) has been meaningless for quite some time, since jemalloc uses mmap to get more space. -Ben