diff options
author | Carlos O'Donell <carlos@systemhalted.org> | 2015-09-14 15:32:47 -0400 |
---|---|---|
committer | Carlos O'Donell <carlos@systemhalted.org> | 2015-09-14 15:32:47 -0400 |
commit | ca6be1655bd357bf6ac8857fba9b9dce928edbdc (patch) | |
tree | 1f030adeac88ff75dcdc411352733b27ec5f3bf9 /manual | |
parent | 3b2cc56dbcbee6bc211cbb58a08384aa6147f825 (diff) | |
download | glibc-ca6be1655bd357bf6ac8857fba9b9dce928edbdc.tar.gz glibc-ca6be1655bd357bf6ac8857fba9b9dce928edbdc.tar.xz glibc-ca6be1655bd357bf6ac8857fba9b9dce928edbdc.zip |
Use ALIGN_DOWN in systrim.
While doing code review I converted another bespoke round down, and corrected a comment. The comment spoke about keeping at least one page allocated even during systrim, which is not correct. The code does nothing to keep a page allocated. The code does attempt to keep PAD padding as documented in comments and MINSIZE as required by design. Historically in 2002 when Ulrich wrote the code (fa8d436c) the math was inlined into one statement which did reserve an extra page: extra = ((top_size - pad - MINSIZE + (pagesz-1)) / pagesz - 1) * pagesz; There is no reason given for this extra page. In 2010 Anton Branchard's change (b9b42ee0) from division to shifts removed the extra page by dropping the "+ (pagesiz-1), which mean we might have attempted to return -0 via MORECORE. The fix by Will Newton in 2014 added a check for extra being zero (51a7380b). From first principles I see no reason why we should keep an extra page of memory from being trimmed back to the OS. The only sensible interface is to honour PAD padding as the function is documented, with the caveat the MINSIZE is maintained for the top chunk. Given that we've been using this code for 5+ years with no extra page allocated is sufficient evidence that the comment should be changed to match the code that I'm touching. Tested on x86_64 and i686, no regressions.
Diffstat (limited to 'manual')
0 files changed, 0 insertions, 0 deletions