<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc.git/malloc, branch zack/remove-libcrypt</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/'/>
<entry>
<title>malloc: Remove bin scanning from memalign (bug 30723)</title>
<updated>2023-08-15T06:07:36+00:00</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2023-08-10T17:36:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=0dc7fc1cf094406a138e4d1bcf9553e59edcf89d'/>
<id>0dc7fc1cf094406a138e4d1bcf9553e59edcf89d</id>
<content type='text'>
On the test workload (mpv --cache=yes with VP9 video decoding), the
bin scanning has a very poor success rate (less than 2%).  The tcache
scanning has about 50% success rate, so keep that.

Update comments in malloc/tst-memalign-2 to indicate the purpose
of the tests.  Even with the scanning removed, the additional
merging opportunities since commit 542b1105852568c3ebc712225ae78b
("malloc: Enable merging of remainders in memalign (bug 30723)")
are sufficient to pass the existing large bins test.

Remove leftover variables from _int_free from refactoring in the
same commit.

Reviewed-by: DJ Delorie &lt;dj@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On the test workload (mpv --cache=yes with VP9 video decoding), the
bin scanning has a very poor success rate (less than 2%).  The tcache
scanning has about 50% success rate, so keep that.

Update comments in malloc/tst-memalign-2 to indicate the purpose
of the tests.  Even with the scanning removed, the additional
merging opportunities since commit 542b1105852568c3ebc712225ae78b
("malloc: Enable merging of remainders in memalign (bug 30723)")
are sufficient to pass the existing large bins test.

Remove leftover variables from _int_free from refactoring in the
same commit.

Reviewed-by: DJ Delorie &lt;dj@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>malloc: Enable merging of remainders in memalign (bug 30723)</title>
<updated>2023-08-11T09:18:17+00:00</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2023-08-11T09:18:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=542b1105852568c3ebc712225ae78b8c8ba31a78'/>
<id>542b1105852568c3ebc712225ae78b8c8ba31a78</id>
<content type='text'>
Previously, calling _int_free from _int_memalign could put remainders
into the tcache or into fastbins, where they are invisible to the
low-level allocator.  This results in missed merge opportunities
because once these freed chunks become available to the low-level
allocator, further memalign allocations (even of the same size are)
likely obstructing merges.

Furthermore, during forwards merging in _int_memalign, do not
completely give up when the remainder is too small to serve as a
chunk on its own.  We can still give it back if it can be merged
with the following unused chunk.  This makes it more likely that
memalign calls in a loop achieve a compact memory layout,
independently of initial heap layout.

Drop some useless (unsigned long) casts along the way, and tweak
the style to more closely match GNU on changed lines.

Reviewed-by: DJ Delorie &lt;dj@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, calling _int_free from _int_memalign could put remainders
into the tcache or into fastbins, where they are invisible to the
low-level allocator.  This results in missed merge opportunities
because once these freed chunks become available to the low-level
allocator, further memalign allocations (even of the same size are)
likely obstructing merges.

Furthermore, during forwards merging in _int_memalign, do not
completely give up when the remainder is too small to serve as a
chunk on its own.  We can still give it back if it can be merged
with the following unused chunk.  This makes it more likely that
memalign calls in a loop achieve a compact memory layout,
independently of initial heap layout.

Drop some useless (unsigned long) casts along the way, and tweak
the style to more closely match GNU on changed lines.

Reviewed-by: DJ Delorie &lt;dj@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>malloc: Fix set-freeres.c with gcc 6</title>
<updated>2023-07-26T12:45:22+00:00</updated>
<author>
<name>Adhemerval Zanella Netto</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2023-07-24T17:15:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=7dfa534ef07cffe9ddb2614e25fbb2e9ae193164'/>
<id>7dfa534ef07cffe9ddb2614e25fbb2e9ae193164</id>
<content type='text'>
Old GCC might trigger the the comparison will always evaluate as ‘true’
warnig for static build:

set-freeres.c:87:14: error: the comparison will always evaluate as
‘true’ for the address of ‘__libc_getgrgid_freemem_ptr’ will never be
NULL [-Werror=address]
   if (&amp;__ptr != NULL)      \

So add pragma weak for all affected usages.

Checked on x86_64 and i686 with gcc 6 and 13.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Old GCC might trigger the the comparison will always evaluate as ‘true’
warnig for static build:

set-freeres.c:87:14: error: the comparison will always evaluate as
‘true’ for the address of ‘__libc_getgrgid_freemem_ptr’ will never be
NULL [-Werror=address]
   if (&amp;__ptr != NULL)      \

So add pragma weak for all affected usages.

Checked on x86_64 and i686 with gcc 6 and 13.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>realloc: Limit chunk reuse to only growing requests [BZ #30579]</title>
<updated>2023-07-06T15:10:27+00:00</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh@sourceware.org</email>
</author>
<published>2023-07-06T15:09:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=2fb12bbd092b0c10f1f2083216e723d2406e21c4'/>
<id>2fb12bbd092b0c10f1f2083216e723d2406e21c4</id>
<content type='text'>
The trim_threshold is too aggressive a heuristic to decide if chunk
reuse is OK for reallocated memory; for repeated small, shrinking
allocations it leads to internal fragmentation and for repeated larger
allocations that fragmentation may blow up even worse due to the dynamic
nature of the threshold.

Limit reuse only when it is within the alignment padding, which is 2 *
size_t for heap allocations and a page size for mmapped allocations.
There's the added wrinkle of THP, but this fix ignores it for now,
pessimizing that case in favor of keeping fragmentation low.

This resolves BZ #30579.

Signed-off-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
Reported-by: Nicolas Dusart &lt;nicolas@freedelity.be&gt;
Reported-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Reviewed-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Tested-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The trim_threshold is too aggressive a heuristic to decide if chunk
reuse is OK for reallocated memory; for repeated small, shrinking
allocations it leads to internal fragmentation and for repeated larger
allocations that fragmentation may blow up even worse due to the dynamic
nature of the threshold.

Limit reuse only when it is within the alignment padding, which is 2 *
size_t for heap allocations and a page size for mmapped allocations.
There's the added wrinkle of THP, but this fix ignores it for now,
pessimizing that case in favor of keeping fragmentation low.

This resolves BZ #30579.

Signed-off-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
Reported-by: Nicolas Dusart &lt;nicolas@freedelity.be&gt;
Reported-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Reviewed-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Tested-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>malloc: Decrease resource usage for malloc tests</title>
<updated>2023-06-12T17:45:24+00:00</updated>
<author>
<name>Adhemerval Zanella Netto</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2023-06-07T17:39:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=94384bdf3955e59f508a6d927065fe0aa824d82b'/>
<id>94384bdf3955e59f508a6d927065fe0aa824d82b</id>
<content type='text'>
The tst-mallocfork2 and tst-mallocfork3 create large number of
subprocesss, around 11k for former and 20k for latter, to check
for malloc async-signal-safeness on both fork and _Fork.  However
they do not really exercise allocation patterns different than
other tests fro malloc itself, and the spawned process just exit
without any extra computation.

The tst-malloc-tcache-leak is similar, but creates 100k threads
and already checks the resulting with mallinfo.

These tests are also very sensitive to system load (since they
estresss heavy the kernel resource allocation), and adding them
on THP tunable and mcheck tests increase the pressure even more.

For THP the fork tests do not add any more coverage than other
tests.  The mcheck is also not enable for tst-malloc-tcache-leak.

Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The tst-mallocfork2 and tst-mallocfork3 create large number of
subprocesss, around 11k for former and 20k for latter, to check
for malloc async-signal-safeness on both fork and _Fork.  However
they do not really exercise allocation patterns different than
other tests fro malloc itself, and the spawned process just exit
without any extra computation.

The tst-malloc-tcache-leak is similar, but creates 100k threads
and already checks the resulting with mallinfo.

These tests are also very sensitive to system load (since they
estresss heavy the kernel resource allocation), and adding them
on THP tunable and mcheck tests increase the pressure even more.

For THP the fork tests do not add any more coverage than other
tests.  The mcheck is also not enable for tst-malloc-tcache-leak.

Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Move {read,write}_all functions to a dedicated header</title>
<updated>2023-06-06T12:23:53+00:00</updated>
<author>
<name>Frédéric Bérat</name>
<email>fberat@redhat.com</email>
</author>
<published>2023-06-02T15:28:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=200ae471b65354eed6f1bc7658f898f2f380951a'/>
<id>200ae471b65354eed6f1bc7658f898f2f380951a</id>
<content type='text'>
Since these functions are used in both catgets/gencat.c and
malloc/memusage{,stat}.c, it make sense to move them into a dedicated
header where they can be inlined.

Reviewed-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since these functions are used in both catgets/gencat.c and
malloc/memusage{,stat}.c, it make sense to move them into a dedicated
header where they can be inlined.

Reviewed-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix a few more typos I missed in previous round -- BZ 25337</title>
<updated>2023-06-02T23:46:32+00:00</updated>
<author>
<name>Paul Pluzhnikov</name>
<email>ppluzhnikov@google.com</email>
</author>
<published>2023-06-02T03:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=2cbeda847bb58bfac73d2048e3e0300ff1b2b894'/>
<id>2cbeda847bb58bfac73d2048e3e0300ff1b2b894</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix all the remaining misspellings -- BZ 25337</title>
<updated>2023-06-02T01:39:48+00:00</updated>
<author>
<name>Paul Pluzhnikov</name>
<email>ppluzhnikov@google.com</email>
</author>
<published>2023-05-20T13:37:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=7f0d9e61f40c669fca3cfd1e342fa8236c7220b7'/>
<id>7f0d9e61f40c669fca3cfd1e342fa8236c7220b7</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>malloc/{memusage.c, memusagestat.c}: fix warn unused result</title>
<updated>2023-06-01T17:00:03+00:00</updated>
<author>
<name>Frédéric Bérat</name>
<email>fberat@redhat.com</email>
</author>
<published>2023-06-01T14:27:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=b97c5efdcae89d17c8ea715a5b814aab9d3cf618'/>
<id>b97c5efdcae89d17c8ea715a5b814aab9d3cf618</id>
<content type='text'>
Fix unused result warnings, detected when _FORTIFY_SOURCE is enabled in
glibc.
Reviewed-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix unused result warnings, detected when _FORTIFY_SOURCE is enabled in
glibc.
Reviewed-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>aligned_alloc: conform to C17</title>
<updated>2023-05-08T20:40:10+00:00</updated>
<author>
<name>DJ Delorie</name>
<email>dj@redhat.com</email>
</author>
<published>2023-03-21T04:46:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/glibc.git/commit/?id=d1417176a35d27ffb8da0ffb1e33154163b6eeb2'/>
<id>d1417176a35d27ffb8da0ffb1e33154163b6eeb2</id>
<content type='text'>
This patch adds the strict checking for power-of-two alignments
in aligned_alloc(), and updates the manual accordingly.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds the strict checking for power-of-two alignments
in aligned_alloc(), and updates the manual accordingly.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
