<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 14, 2017 at 2:17 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
>    Well it actually does something malloc doesn't do. It allows for<br>
>    multiple malloc backends,<br>
<br>
</span>A malloc implementation can have multiple arenas.<br></blockquote><div><br></div><div>Sure.  But are we confident that one of these multiple-arena malloc()s will work for whatever combinations of different types of memory we'll need?  Maybe the answer is yes; if so, then we don't need to support multiple mallocs, we just need to provide a mechanism to use one of these mallocs and specify which kind of memory to prefer/require.  Though the corresponding free() will need to be able to determine the appropriate kind of memory without PETSc needing to tell it, as otherwise we need this hash table or whatever...<br><br></div><div>--Richard<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>    and possibly allows for other things like tracking how often the<br>
>    malloced space is accessed.<br>
<br>
</span>How?<br>
<span class=""><br>
>    And keeps enough information for migration of malloced space.<br>
<br>
</span>What does that mean?<br>
<br>
</blockquote></div><br></div></div>