From owner-freebsd-hackers@freebsd.org  Fri Nov 18 09:10:07 2016
Return-Path: <owner-freebsd-hackers@freebsd.org>
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 AAAF5C4648E
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Fri, 18 Nov 2016 09:10:07 +0000 (UTC)
 (envelope-from matthias.andree@gmx.de)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 096C2132B;
 Fri, 18 Nov 2016 09:10:06 +0000 (UTC)
 (envelope-from matthias.andree@gmx.de)
Received: from mandree.no-ip.org ([78.48.229.43]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lu3J4-1cnpwf3REk-011VS0; Fri, 18
 Nov 2016 10:09:52 +0100
Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1])
 by apollo.emma.line.org (Postfix) with ESMTP id E32C223CEBD;
 Fri, 18 Nov 2016 10:09:44 +0100 (CET)
Subject: Re: sbrk(0) replacement for memory resource tracking?
To: Ed Maste <emaste@freebsd.org>
References: <20161110012624.GA23701@lonesome.com>
 <dd964b1d-db3c-94d4-794b-929b28326430@gmx.de>
 <20161110215549.GL91607@kduck.kaduk.org>
 <a8a85ea4-b9af-cc6a-0573-d23967b4d82c@gmx.de>
 <CAPyFy2BD=0exCq=1odNo6=5x+UyZUVs+mB37K_mG=6fVBOowUQ@mail.gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>,
 "freebsd-hackers@FreeBSD.org" <freebsd-hackers@FreeBSD.org>,
 "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>,
 Mark Linimon <linimon@lonesome.com>
From: Matthias Andree <matthias.andree@gmx.de>
Message-ID: <56d3f59d-29e7-f98d-af25-e39c51a85f11@gmx.de>
Date: Fri, 18 Nov 2016 10:09:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAPyFy2BD=0exCq=1odNo6=5x+UyZUVs+mB37K_mG=6fVBOowUQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:Y9Rt5wMcXpSkNiOGSBUhnCx5643mHguDLCACbBGU8Vp+j9zNUvS
 c4o3lRcNEJiyW/T+K5TniQg8JqBzrOWzjpkqFqi9zucaGVJ9MKT3L6Tct3WVzfd1LlIDD7J
 SIFCb4CDG3YHl6mk9KNKPn8As/t3mnQ2qtFx9RyNUaNEHDk1BzZTyD9Rmn9EF6DyNsFsIfL
 P1kxRZ/OxTFS7vGqlKwJA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:j5jN3pFNjHU=:Id7Gcr6U6WJTT++1gkowVJ
 SHXZVAkrHlUEuN6nTsf43O6bymjK+TLSkgct6zqX6A0PYCnDbcbvQLvf3URXNncDB8tCjmY7g
 kokAmcMnqi/6gJhdIWC4P0LXP3oB4Xgr27l7fbEEhrxhU2cQ22CkaE5H08xtixI1vaPQoF7ZB
 FE+Z9aSF0doPaoMVmoxmA6FKJztKdWWWdubSPT//JObywejqAdvc+660xjZdsRVsW4Qj1a66s
 cOkjkxJBRPOwBJsn2jT8TVMMOdOxroPbnbPWUPe/YVKFa9j//5e93OMixtrHOZglUMGkAT6Mm
 SfNBcG6pIQ2Hbrq3ESsfp9Y85edhEnMwh3dUj7dhewXbZRCzATxfNC1uh08osK8myr8oWSUbw
 WkrCy+IwlJ5wMszQFZvF6aLNrgZtBWk04MIg1VR/0A/XiWxRUuNOH3XkKcjxkEg19YeTagPv/
 r7YTLa+q0BKPnOXXKukkVMyyN9C019xkZFkzW051hU1NddEFxr6TtW9cCXieT0aS/P+nx6Bd7
 nB3v0BxjKdUXw1fMgJrcVdsaTMDnD7/MISv6PGh29VZZKhx7NLHsdn+aLNg5/LbvFeOof7cFK
 J3EsE2MhB0hvM23wONuumYiPefPhB6paiRTwpmXISLHGZiCRjOmXSNF2snvm2fhjUfBXHynHQ
 51ATNEA/WpaWM7Pn6gXcjNcmomcz1NtlVDBx0/8gg1LL7oUfEuPz0C7y9jlAoY11sZveaKxQj
 IDoUZW1LHkWqVr2GoXsZ8Umi2nZYzdcoHOlpudBuIogYqDH5k/cqZ665mBJeErgawgXBdDJnH
 EbjB1xV
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2016 09:10:07 -0000

Am 17.11.2016 um 20:41 schrieb Ed Maste:
> That seems broadly sensible to me, and I think it will be useful to
> have a few worked examples to demonstrate collection of memory stats
> with jemalloc.


Thanks.

Before going the jemalloc-example way in e2fsprogs, I'd contact the
upstream maintainer if that's sensible at all, because it's mostly a
maintainer/developer feature for a tool set that originates in Linux,
and given we don't have ext3/ext4 write support in the FreeBSD kernels
currently, nor a FUSE module TTBOMK, I think e2fsprogs will remain in a
niche.

The upstream author was kind enough to invest a lot of time into sorting
the FreeBSD portability out with me, which is more than we could have
asked for.

So, regarding jemalloc, what's the best way to detect it, probe features
from an autoconf test, or look at the FreeBSD version macros?

On a different note, we also figured that the default TMPDIR locations
often do not provide sparse file support (and setting up a ram disk with
UFS to obtain sparse file support requires privileges, which I try to
avoid requiring from a port build), while on-disk locations (for
instance, inside the port's $WRKSRC) with sparse file support slow down
the self-test suite considerably if using spinning magnetic platter
stacks...