<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 28, 2015 at 5:26 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 Apr 27, 2015, at 1:51 PM, Richard Mills <<a href="mailto:rtm@utk.edu">rtm@utk.edu</a>> wrote:<br>
><br>
> All,<br>
><br>
> 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>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> I think it is possible to add the memkind support without breaking all of the interfaces used throughout PETSc for PetscMalloc(), etc.<br>
<br>
</span> I don't think having this as a goal is useful at all! Just break the current interface; add an abstract "memkind" argument to all PetscMalloc() and Free() calls that indicates any additional information about the memory requested. By making it "abstract" it will always just be there and on systems without any special memory options it just doesn't do anything.<br></blockquote><div><br></div><div>Since Malloc() is so pervasive, I think it would be useful to have a 2 level interface here. The standard Malloc() would call</div><div>you advanced PlacedMalloc(), and anyone could call that function, but I think its just cruel to make everyone allocating</div><div>memory give arguments they do not understand or need.</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Barry<br>
<br>
Note: it is not clear to me how this could be helpful on its own because I agree with Jed how is the user when creating the object supposed to know the optimal place to put the object? For more complex objects it may be that different parts of the object would be stored in different types of memory etc etc.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> 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<br>
><br>
> PetcErrorCode PetscMemkindMalloc(size_t size, const char *func, const char *file, void **result)<br>
><br>
> {<br>
><br>
> struct memkind *kind;<br>
><br>
> int err;<br>
><br>
><br>
> if (*result == NULL) {<br>
><br>
> kind = MEMKIND_DEFAULT;<br>
><br>
> }<br>
><br>
> else {<br>
><br>
> kind = (struct memkind *)(*result);<br>
><br>
> }<br>
><br>
><br>
> err = memkind_posix_memalign(kind, result, 16, size);<br>
><br>
> return PosixErrToPetscErr(err);<br>
><br>
> }<br>
><br>
><br>
> and ifree will look something like:<br>
><br>
> PetcErrorCode PetscMemkindFree(void *ptr, int a, const char *func, const char *file)<br>
><br>
> {<br>
><br>
> memkind_free(0, ptr);<br>
><br>
> return 0;<br>
><br>
> }<br>
><br>
><br>
> 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?<br>
><br>
> Thoughts? I'd like to hash out something soon and start writing some code.<br>
><br>
> --Richard<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>