<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 3, 2015 at 6:54 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>
> On Wed, Jun 3, 2015 at 6:04 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
</span><span class="">>> Have you heard anything back about whether move_pages() will work?<br>
>><br>
><br>
> move_pages() will work to move pages between MCDRAM and DRAM right<br>
> now,<br>
<br>
</span>Great!<br>
<span class=""><br>
> but it screws up memkind's partitioning of the heap (it won't be aware<br>
> that the pages have been moved).<br>
<br>
</span>Then memkind is stupid or the kernel isn't exposing the correct<br>
information to memkind.  Tell them to not be lazy and do it right.<br></blockquote><div><br></div><div>I believe that it really comes down to a problem with what the Linux kernel allows right now.  To do this "right" we need to hack the kernel.  Memkind is working within the constraints of what the kernel currently does.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Jed, I'm with you in thinking that, ultimately, there actually needs to be<br>
> a way to make these kinds of decisions based on global information.  We<br>
> don't have that right now.  But if we get some smart allocator (and<br>
> migrator) that gives us, say malloc_use_oracle() to always make the good<br>
> decision,<br>
<br>
</span>The oracle has to see into the future.  move_pages() is so much more<br>
powerful.<br>
<span class=""><br>
> we still should have something like a PetscAdvMalloc() that provides a<br>
> context to allow us to pass advice to this smart allocator to provide<br>
> hints about how it will be accessed, whatever.<br>
<br>
</span>What does the caller know?  What good is the context if we always pass<br>
I_HAVE_NO_IDEA?<br>
<span class=""><br>
> In a lot of cases, simple size-based allocation is probably the way to go.<br>
> An option to do automatic size-based placement is even in the latest<br>
> memkind sources on github now, but it will do that for the entire<br>
> application.<br>
<br>
</span>That's crude; I'd rather have each library use its own threshold.<br>
<span class=""><br>
> I'd like to be able to restrict this to only the PETSc portion: Maybe<br>
> a code that uses PETSc also needs to allocate some enormous lookup<br>
> tables that are big but have accesses that are really latency- rather<br>
> than bandwidth-sensitive.  Or, to be specific to a code I actually<br>
> know, I believe that in PFLOTRAN there are some pretty large<br>
> allocations required for auxiliary variables that don't need to go in<br>
> high-bandwidth memory, though we will want all of the large PETSc<br>
> objects to go in there.<br>
<br>
</span>Fine.  That involves a couple lines of code.  Go into PetscMallocAlign<br>
and add the ability to use memkind.  Add a run-time option to control<br>
the threshold.  Done.<br></blockquote><div><br></div><div>Hmm.  That's a simpler solution that may be better.  I'm not sure that it will always be the best thing to do, but in cases where it is appropriate, that simple option sounds like something we should support.</div><div><br></div><div>I assume you'd also like an option to specify that the allocation should fail if high bandwidth memory cannot be allocated, to avoid seeing very confusing performance.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you want complexity to bleed into the library (and necessarily into<br>
user code if given any power at all), I think you need to demonstrate a<br>
tangible benefit that cannot be obtained by something simpler.  Consider<br>
the simple and dumb threshold above to be the null hypothesis.<br>
<br>
This is just my opinion.  Feel free to make a branch with whatever you<br>
prefer.<br>
</blockquote></div><br></div></div>