<html>#2354: consider using malloc_trim after regrid to return memory to the OS
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Roland Haas</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Carpet</td></tr>
</table>
<p>Memory usage in an AMR run can be quite uneven between MPI ranks and also tends to peak during a regrid. See #2194 for a case study. The growth in RSS can eventually lead to OOM situations as memory is not returned to the OS for use by other processes. Using the (GNU extension) <code>malloc_trim</code> can help make the <code>malloc</code> code return memory to the OS. Since this somewhat slows down future <code>malloc</code> calls, since a new allocation will require a round trip to the kernel, this should not done after every single <code>free</code> call but likely only after a regrid which entails a temporary spike in memory usage. Possible also after IO if the memory used to send data to rank 0 for writing becomes an issue (see #1853).</p>
<p>Similar effects to calling <code>malloc_trim</code> can be achieved by setting env variables as mentioned in #2194.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2354/consider-using-malloc_trim-after-regrid-to'>https://bitbucket.org/einsteintoolkit/tickets/issues/2354/consider-using-malloc_trim-after-regrid-to</a></p>
</html>