Date: Thu, 10 Nov 2016 23:26:37 +0100 From: Matthias Andree <matthias.andree@gmx.de> To: Benjamin Kaduk <kaduk@mit.edu> Cc: "freebsd-hackers@FreeBSD.org" <freebsd-hackers@FreeBSD.org>, Mark Linimon <linimon@lonesome.com> Subject: Re: sbrk(0) replacement for memory resource tracking? Message-ID: <a8a85ea4-b9af-cc6a-0573-d23967b4d82c@gmx.de> In-Reply-To: <20161110215549.GL91607@kduck.kaduk.org> References: <20161110012624.GA23701@lonesome.com> <dd964b1d-db3c-94d4-794b-929b28326430@gmx.de> <20161110215549.GL91607@kduck.kaduk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 10.11.2016 um 22:55 schrieb Benjamin Kaduk: > 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 a= t >>> 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 m= e >>> 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 simila= r 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 Free= BSD12. > At the time I somehow convinced myself that it had never been in a stab= le > 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 ne= cessarly > 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. OK. So the quick and dirty way to re-enable e2fsprogs on those architectures whilst scrapping any memory statistics would be to #define sbrk(a) (a) which would just invalidate stats, providing the application handles bogus data. Other than that, it would seem that mallctl("epoch", ...) to synch up stats, and mallctl("stats.active", ...) or perhaps or "stats.mapped" gets me close to what comparing sbrk(0) over process lifetime would have achieved, wouldn't it? This is assuming sbrk() had page granularity anyhow and stats.active provides exactly that (gross memory allocated). Possibly this also wants mallctlnametomib and mallctlbymib for optimization if called often. Right?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a8a85ea4-b9af-cc6a-0573-d23967b4d82c>