<html>#2194: Memory increase during regridding
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Wolfgang Kastaun</td></tr>
<tr><td style='text-align:right'> Status:</td><td>open</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td>ET_2019_02</td></tr>
<tr><td style='text-align:right'> Version:</td><td>development version</td></tr>
<tr><td style='text-align:right'> Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Other</td></tr>
</table>
<p>Comment (by Roland Haas):</p>
<p><code>tcmalloc</code> is indead the better solution to this and may well actually take care of your out-of-memory situation altogether. It is very easy to install and can be used as well on clusters. In the past we have also found that running with <code>tcmalloc</code> can give a noticeable speedup for some codes compared to running just with <code>glibc</code> (a speedup measurable in the <code>physical_time_per_hour</code> measurement, though the code was not actually <code>Cactus</code> based).</p>
<p>Having said this, that is also the reason why I did not use it for this test since I wanted to see if I can still get the increase in rss (which does not come from mallinfo but from reading /proc so is "safe") before/after the patch. In this case I think <code>mallinfo()</code> is still trustworthy since I am running with less than 2GB per rank anyway.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2194/memory-increase-during-regridding'>https://bitbucket.org/einsteintoolkit/tickets/issues/2194/memory-increase-during-regridding</a></p>
</html>