Date: Thu, 17 Nov 2016 14:41:52 -0500 From: Ed Maste <emaste@freebsd.org> To: Matthias Andree <matthias.andree@gmx.de> Cc: Benjamin Kaduk <kaduk@mit.edu>, "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org>, Mark Linimon <linimon@lonesome.com> Subject: Re: sbrk(0) replacement for memory resource tracking? Message-ID: <CAPyFy2BD=0exCq=1odNo6=5x%2BUyZUVs%2BmB37K_mG=6fVBOowUQ@mail.gmail.com> In-Reply-To: <a8a85ea4-b9af-cc6a-0573-d23967b4d82c@gmx.de> References: <20161110012624.GA23701@lonesome.com> <dd964b1d-db3c-94d4-794b-929b28326430@gmx.de> <20161110215549.GL91607@kduck.kaduk.org> <a8a85ea4-b9af-cc6a-0573-d23967b4d82c@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I seem to be missing the beginning of this thread, so pardon the lack
of context in quotes below.
>>> 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.
Stable/11 never provided sbrk on arm64, and sbrk is not in the first
FreeBSD release to support arm64, 11.0. Right now nothing changes for
existing architectures, which continue to provide sbrk.
>>> 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.
Indeed, and that's no worse than today: applications calling sbrk(0)
to measure memory use are already handling 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?
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2BD=0exCq=1odNo6=5x%2BUyZUVs%2BmB37K_mG=6fVBOowUQ>