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 /sysdeps/i386 | |
parent | 3b2cc56dbcbee6bc211cbb58a08384aa6147f825 (diff) | |
download | glibc-ca6be1655bd357bf6ac8857fba9b9dce928edbdc.tar.gz |
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 'sysdeps/i386')
0 files changed, 0 insertions, 0 deletions