sbrk(0) replacement for memory resource tracking? (was: [linimon at 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...])
Benjamin Kaduk
kaduk at mit.edu
Thu Nov 10 22:01:04 UTC 2016
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
More information about the freebsd-hackers
mailing list