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

[Brooks Davis]

On Thu, Nov 10, 2016 at 03:55:50PM -0600, Benjamin Kaduk wrote:
> 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].

It's never been in a release on either architecture.

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

As you point out, sbrk(0) does not show memory usage in a useful way for
normal programs.  If you enable ASR/ASLR it gets even more useless.  An
implementation that returns NULL should satisfy most code that abuses it
for memory use and provide no less value.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20161110/464c600e/attachment.sig>