<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 3, 2015 at 6:04 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="">Richard Mills <<a href="mailto:rtm@utk.edu">rtm@utk.edu</a>> writes:<br>
<br>
> It's been a while, but I'd like to pick up this discussion of adding a<br>
> context to memory allocations again.<br>
<br>
</span>Have you heard anything back about whether move_pages() will work?<br></blockquote><div><br></div><div>move_pages() will work to move pages between MCDRAM and DRAM right now, but it screws up memkind's partitioning of the heap (it won't be aware that the pages have been moved).  (Which calls to mind the question I raised somewhere back in this thread of whether we even need a heap manager for the large allocations.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> hbw_preferred_str = (char *)memkind_malloc(MEMKIND_HBW_PREFERRED, size);<br>
<br>
</span>How much would you prefer it?  If we stupidly ask for HBM in VecCreate_*<br>
and MatCreate_*, then our users will see catastrophic performance drops<br>
at magic sizes and will have support questions like "I swapped these two<br>
independent lines and my code ran 5x faster".  Then they'll hack the<br>
source by writing<br>
<br>
  if (moon_is_waxing() && operator_holding_tongue_in_right_cheek()) {<br>
    policy = MEMKIND_HBW_PREFERRED;<br>
  }<br>
<br>
eventually making all decisions based on nonlocal information, ignoring<br>
the advice parameter.<br>
<br>
Then they'll get smart and register their own malloc so they don't have<br>
to hack the library.  Then they'll try to couple their application with<br>
another that does the same thing and now they have to write a new malloc<br>
that makes a new set of decisions in light of the fact that multiple<br>
libraries are being coupled.<br>
<br>
I think we can agree that this is madness.  Where do you draw the line<br>
and say that crappy performance is just reality?<br>
<br>
It's hard for me not to feel like the proposed system will be such a<br>
nightmarish maintenance burden with such little benefit over a simple<br>
size-based allocation that it would be better for everyone if it doesn't<br>
exist.<br></blockquote><div><br></div><div>Jed, I'm with you in thinking that, ultimately, there actually needs to be a way to make these kinds of decisions based on global information.  We don't have that right now.  But if we get some smart allocator (and migrator) that gives us, say malloc_use_oracle() to always make the good decision, we still should have something like a PetscAdvMalloc() that provides a context to allow us to pass advice to this smart allocator to provide hints about how it will be accessed, whatever.</div><div><br></div><div>I know you don't like the memkind model, and I'm not thrilled with it either (though it's what I've got to work with right now), but the interface changes I'm proposing are applicable to other approaches.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For example, we've already established that small allocations should<br>
generally go in DRAM because they're either cached or not prefetched and<br>
thus limited by latency instead of bandwidth.  Large allocations that<br>
get used a lot should go in HBM so long as they fit.  Since we can't<br>
determine "used a lot" or "fit" from any information possibly available<br>
in the calling scope, there's literally no useful advice we can provide<br>
at that point.  So don't try, just set a dumb threshold (crude tuning<br>
parameter) or implement a profile-guided allocation policy (brittle).<br></blockquote><div><br></div><div>In a lot of cases, simple size-based allocation is probably the way to go.  An option to do automatic size-based placement is even in the latest memkind sources on github now, but it will do that for the entire application.  I'd like to be able to restrict this to only the PETSc portion: Maybe a code that uses PETSc also needs to allocate some enormous lookup tables that are big but have accesses that are really latency- rather than bandwidth-sensitive.  Or, to be specific to a code I actually know, I believe that in PFLOTRAN there are some pretty large allocations required for auxiliary variables that don't need to go in high-bandwidth memory, though we will want all of the large PETSc objects to go in there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or ignore all this nonsense, implement move_pages(), and we'll have PETSc<br>
track accesses so we can balance the pages once the app gets going.<br>
<span class=""><br>
> Of course, we'll need some way to ensure that the "advanced malloc"<br>
<br>
</span>I thought AdvMalloc was short for AdvisedMalloc.<br></blockquote><div><br></div><div>Oh, hey, I do like "Advised" better. </div><div><br></div><div>--Richard</div></div><br></div></div>