sbrk(0) replacement for memory resource tracking?

[Matthias Andree]

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...