<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 10, 2017 at 11:52 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 10, 2017, at 12:04 AM, Richard Mills <<a href="mailto:richardtmills@gmail.com">richardtmills@gmail.com</a>> wrote:<br>[...]<br>
> Personally, I think that memkind is something we should support it in PETSc.<br>
<br>
</span>   Yes, the question is how do we "support it"? Do we have a PETSc malloc API and then it can direct the calls down to "classic malloc(), memkind, .....? At this time I think saying the PETSc malloc API is "just" the memkind API would be a mistake.  If we have a PETSc malloc API* what is crucial to have in the PETSc malloc API? And what should the API look like. Three things that could/should possibly be exposed are: "kind of memory", alignment (if doing SIMD this might/is important), page size (these three things are exposed by memkind/hbm_xxx().<br>
<br>
<br>
* PETSc currently does have a Petsc malloc API but it has always been kept exceedingly limited, so the question is more if we extend it and how we extend it.<br></blockquote><div><br></div><div>I think there are two questions here: What is the long-term solution (hard to answer) and what is the short-term fix we can implement right now so that Mr. Hong can make his adjoint code work in a slightly less kludgy way.  Shortest term, I think Hong can do basically what he has been doing, but he should have two "malloc" commands (and "high-bandwidth" and a "normal DRAM" version) that he sets, both of which use the memkind interface.  He should just use one "free" command, which is uses the memkind interface but does not specify the "kind" of memory -- this will work to free anything that memkind has allocated.  This approach requires no changes to the existing PETSc API.<br><br></div><div>Less short term, I like Barry's idea of allocating a bit of extra memory to track things like what free() should be used.  If we want to avoid tracking as much global state but also detect memory corruption, we could store a pointer to the free() routine and then write some extra stuff in there (we will have a whole cache line) to help detect corruption (if error checking is turned on).  If we don't care about global state, then whatever.<br><br></div><div>I also like the idea of a stack for the malloc()s to use.  I actually like this both for the "advise" version and just as an alternative to having to do a PetscMallocClear() followed by a new PetscMallocSet() every time one wants to switch from something like a "high-bandwidth" allocator back to some default.<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>
<br>
>  That doesn't mean it's the ideal solution, but it has utility now.  We can certainly support something else when something better arrives.<br>
<br>
</span>  Disappointing on my Mac.<br>
<br>
WARNING: Could not locate OpenMP support. This warning can also occur if compiler already supports OpenMP<br>
checking omp.h usability... no<br>
checking omp.h presence... no<br>
checking for omp.h... no<br>
omp.h is required for this library<br>
<br>
   Now I have read through all the old email from Jed to understand why he hates memkind so much.<br>
<span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> --Richard<br>
><br>
><br>
> Jeff<br>
><br>
> --Richard<br>
><br>
><br>
> Jeff<br>
><br>
> Perhaps I should try memkind calls since they may become much better.<br>
><br>
> Hong (Mr.)<br>
><br>
> --<br>
> Jeff Hammond<br>
> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
> <a href="http://jeffhammond.github.io/" rel="noreferrer" target="_blank">http://jeffhammond.github.io/</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Jeff Hammond<br>
> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
> <a href="http://jeffhammond.github.io/" rel="noreferrer" target="_blank">http://jeffhammond.github.io/</a><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>