<div dir="ltr">All,<div><br></div><div>I'd like to add support for the allocators provided by the 'memkind' library (<a href="https://github.com/memkind/memkind" target="_blank">https://github.com/memkind/memkind</a>).  I've discussed memkind a little bit with some of you off-list.  Briefly, memkind provides a "user extensible heap manager built on top of jemalloc which enables control of memory characteristics and a partitioning of the heap between kinds of memory".  The immediate motivation is to support placement of critical data structures into the high bandwidth on-package memory that will be available with Intel's "Knights Landing" generation of Xeon Phi processor (like on the upcoming NERSC Cori machine), but what the library provides is more general, and it can also be used for placing data in memory such as nonvolatile RAM (NVRAM), which will be appearing in more systems.<br></div><div><br></div><div>I'm with Jed in thinking that, ideally, PETSc (or its users) shouldn't have to make decisions about the optimal way to solve the "packing problem" of what should go into high-bandwidth memory.  (In fact, I think this is a really interesting research problem that relates to some work on memory-adaptation in scientific applications that I did back when I was doing my Ph.D. research, e.g., <a href="http://www.climatemodeling.org/~rmills/pubs/JGC_mmlib_2007.pdf" target="_blank">http://www.climatemodeling.org/~rmills/pubs/JGC_mmlib_2007.pdf</a>.)  However, right now I'd like to take the baby step of coming up with a mechanism to simply tag PETSc objects with a kind of memory that is preferred, and then having associated allocations reflect that preference (or requirement, if the user wants allocations to fail if such memory is not available).  Later we can worry about how to move data structures in and out of a kind of memory.</div><div><br></div><div>It might make sense to add an option for certain PETSc classes--Mat and Vec are the most obvious here--to prefer allocations in a certain kind of memory.  Or, would it make more sense to add such an option at the PetscObject level?</div><div><br></div><div>I think it is possible to add the memkind support without breaking all of the interfaces used throughout PETSc for PetscMalloc(), etc.  I recently sat with Chris Cantalupo, the main memkind developer, and walked him through PETSc's allocation routines, and we came up with the following: The imalloc() function pointer could have an implementation something like</div><div><br></div><div><p class="MsoNormal"><span style="font-family:'Courier New'">PetcErrorCode PetscMemkindMalloc(size_t size, const char
*func, const char *file, void **result)</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">{</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    struct memkind
*kind;</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    int err;</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'"> </span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    if (*result ==
NULL) {</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">        kind =
MEMKIND_DEFAULT;</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    }</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    else {</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">        kind = (struct
memkind *)(*result);</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    }</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    </span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    err =
memkind_posix_memalign(kind, result, 16, size);</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    return
PosixErrToPetscErr(err);</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">}</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'"> </span></p>

and ifree will look something like:

<p class="MsoNormal"><span style="font-family:'Courier New'"> </span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">PetcErrorCode PetscMemkindFree(void *ptr, int a, const char
*func, const char *file)</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">{</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    memkind_free(0,
ptr);</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">    return 0;</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'">}</span></p>

<p class="MsoNormal"><span style="font-family:'Courier New'"> </span></p>

This gives us (1) a method of passing the kind of memory without modifying the petsc allocation routine calling sequence, and (2) support a fall back code path legacy applications which will not set the pointer to NULL.  Or am I missing something?</div><div><br></div><div>Thoughts?  I'd like to hash out something soon and start writing some code.</div><div><br></div><div>--Richard</div></div>