<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 28, 2015 at 9:35 AM, 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="">Richard Mills <<a href="mailto:rtm@utk.edu">rtm@utk.edu</a>> writes:</span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">[...]<br></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Linux provides the mbind(2) and move_pages(2) system calls that enable the<br>
> user to modify the backing physical pages of virtual address ranges within<br>
> the NUMA architecture, so these can be used to move physical pages between<br>
> NUMA nodes (and high bandwidth on-package memory will be treated as a NUMA<br>
> node).  (A user on a KNL system could actually use move_pages(2) to move<br>
> between DRAM and MCDRAM, I believe.)<br>
<br>
</span>Really?  That's what I'm asking for.<br></blockquote><div><br></div><div>Yes, I am ~ 99% sure that this is the case, but I will double-check to make sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> But Linux doesn't provide an equivalent way for a user to change the<br>
> page size of the backing physical pages of an address range, so it's<br>
> not possible to implement the above memkind_convert() with what Linux<br>
> currently provides.<br>
<br>
</span>For small allocations, it doesn't matter where the memory is located<br>
because it's either in cache or it's not.  From what I hear, KNL's<br>
MCDRAM won't improve latency, so all such allocations may as well go in<br>
DRAM anyway.  So all I care about are substantial allocations, like<br>
matrix and vector data.  It's not expensive to allocate those the align<br>
with page boundaries (provided they are big enough; coarse grids don't<br>
matter).<br></blockquote><div><br></div><div>Yes, MCDRAM won't help with latency, only bandwidth, so for small allocations it won't matter.  Following reasoning like what you have above, a colleague on my team recently developed an "AutoHBW" tool for users who don't want to modify their code at all.  A user can specify a size threshold above which allocations should come from MCDRAM, and then the tool interposes on the malloc() (or other allocator) calls to put the small stuff in DRAM and the big stuff in MCDRAM.</div><div><br></div><div>I think many users are going to want more control than what something like AutoHBW provides, but, as you say, a lot of the time one will only care about the the substantial allocations for things like matrices and vectors, and these also tend to be long lived--plenty of codes will do something like allocate a matrix for Jacobians once and keep it around for the lifetime of the run.  Maybe we should consider not using a heap manager for these allocations, then.  For allocations above some specified threshold, perhaps we (PETSc) should simply do the appropriate mmap() and mbind() calls to allocate the pages we need in the desired type of memory, and then we could use things like use move_pages() if/when appropriate (yes, I know we don't yet have a good way to make such decisions).  This would mean PETSc getting more into the lower level details of memory management, but maybe this is appropriate (an unavoidable) as more kinds of user-addressable memory get introduced.  I think is actually less horrible than it sounds, because, really, we would just want to do this for the largest allocations.  (And this is somewhat analogous to how many malloc() implementations work, anyway: Use sbrk() for the small stuff, and mmap() for the big stuff.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> If we want to move data from one memory kind to another, I believe that we<br>
> need to be able to deal with the virtual address changing.<br>
<br>
</span>That is a regression relative to move_pages.  Just make move_pages work.<br>
That's the granularity I've been asking for all along.<br></blockquote><div><br></div><div>Cannot practically be done using a heap manager system like memkind.  But we can do this if we do our own mmap() calls, as discussed above.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Yes, this is a pain because extra bookkeeping is involved.  Maybe we<br>
> don't want to bother with supporting something like this in PETSc.<br>
> But I don't know of any good way around this.  I have discussed with<br>
> Chris the idea of adding support for asynchronously copying pages<br>
> between different kinds of memory (maybe have a memdup() analog to<br>
> strdup()) and he had some ideas about how this might be done<br>
> efficiently.  But, again, I don't know of a good way to move data to a<br>
> different memory kind while keeping the same virtual address.  If I'm<br>
> misunderstanding something about what is possible with Linux (or other<br>
> *nix), please let me know--I'd really like to be wrong on this.<br>
<br>
</span>Moving memory at page granularity is all you can do.  The hardware<br>
doesn't support virtual-physical mapping at different granularity, so<br>
there is no way to preserve address without affecting everything sharing<br>
that page.  But "memkinds" only matter for large allocations.<br>
<br>
Is it a showstopper to have different addresses and do full copies?<br>
It's more of a mess with threads (requires extra<br>
synchronization/coordination), but it's sometimes (maybe often)<br>
feasible.  It's certainly ugly and a debugging nightmare (e.g., you'll<br>
set a location watchpoint and not see where it was modified because it<br>
was copied out to a different kind).  We'll also need a system for<br>
eviction.<br>
</blockquote></div><br></div></div>