<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 9, 2017 at 7:04 PM, Zhang, Hong <span dir="ltr"><<a href="mailto:hongzhang@anl.gov" target="_blank">hongzhang@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<br>
<div><span class="">
<blockquote type="cite">
<div>On Mar 9, 2017, at 8:50 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:</div>
<br class="m_1567190019085839969Apple-interchange-newline">
<div>
<blockquote type="cite" style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br class="m_1567190019085839969Apple-interchange-newline">
On Mar 9, 2017, at 8:29 PM, Zhang, Hong <<a href="mailto:hongzhang@anl.gov" target="_blank">hongzhang@anl.gov</a>> wrote:<br>
<br>
<br>
<blockquote type="cite">On Mar 9, 2017, at 7:38 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
<br>
<blockquote type="cite">On Mar 9, 2017, at 7:18 PM, Richard Mills <<a href="mailto:richardtmills@gmail.com" target="_blank">richardtmills@gmail.com</a>> wrote:<br>
<br>
Hi Barry,<br>
<br>
I like the sound of this, but I think we'd need to be careful about not messing up data alignment if we do this.  If we want a malloc that is going to let us put the start of an array on, say, a 64 byte alignment boundary, then we need to not mess that up by
 putting this integer value there.  <br>
</blockquote>
<br>
As I said the extra space is 64 bit. Now if you want 128 bit alignment we could put a 128 bit.<br>
<br>
<blockquote type="cite">We could pad with an extra 64 bytes internally, though that may be getting too wasteful.  I don't know how to get a malloc that gives us a starting address that is 64 bits *before* an alignment boundary (so that the memory the
 user sees from the malloc call indeed starts at the boundary), but maybe that's doable...<br>
</blockquote>
<br>
What alignment boundaries are useful for Intel processes? 64 yup, 128, 256, 512 ? Does higher values provide better performance for SIMD etc?<span class="m_1567190019085839969Apple-converted-space"> </span><br>
<br>
<blockquote type="cite"><br>
If the goal is to simply deal with allocations to high bandwidth memory on KNL, the memkind-provided free() will do the right thing with allocations in DRAM or MCDRAM.  <br>
</blockquote>
<br>
Hmm, Hong, how come we don't use this? I didn't realize it worked this way. This would shut Jed up immediately.<br>
</blockquote>
<br>
This is what I have already mentioned in our discussions under the pull request. If we have smarter APIs in the future (and I believe we will), things will be much easier.<br>
<br>
However, hbw_free() in memkind does not work this way yet. If I do the allocation with normal malloc() and free it with hbw_free(),  I will get an SEGV error. If I pair hbw_malloc() with free(), I will also get an SEGV error.<span class="m_1567190019085839969Apple-converted-space"> </span></blockquote></div></blockquote></span></div></div></blockquote><div>If you set the policy to HBW_POLICY_PREFERRED (the default), hbw_malloc() will pefer high-bandwidth memory, but will resort to using normal DRAM if that is all that is available.  But that doesn't mean that it starts using regular malloc() -- it just starts fulfilling its allocation request by using the lower bandwidth partition.  hbw_malloc() places different bookkeeping information in the allocated space than malloc(), so calling free() is going to fail.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><blockquote type="cite" style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>
</blockquote>
<br style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> Yes,
 but why are you using the hwb_ calls instead of using memkind calls? There could be good reasons I am not suggesting calling the memkind ...</span><br style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</div>
</blockquote>
<div><br>
</div>
</span><div>I started to play with memkind last summer. At that time, there were plenty of sayings online like this:  </div>
<div><span style="font-family:'Open Sans',Helvetica,Arial,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">"the </span><i style="margin:0px;padding:0px;border:0px;font-variant-ligatures:normal;font-variant-numeric:inherit;font-stretch:inherit;font-size:14px;line-height:inherit;font-family:'Open Sans',Helvetica,Arial,sans-serif;vertical-align:baseline;background-color:rgb(255,255,255)">hbwmalloc</i><span style="font-family:'Open Sans',Helvetica,Arial,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)"> interface
 is stable but </span><i style="margin:0px;padding:0px;border:0px;font-variant-ligatures:normal;font-variant-numeric:inherit;font-stretch:inherit;font-size:14px;line-height:inherit;font-family:'Open Sans',Helvetica,Arial,sans-serif;vertical-align:baseline;background-color:rgb(255,255,255)">memkind</i><span style="font-family:'Open Sans',Helvetica,Arial,sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)"> interface
 is only partially stable."</span></div>
<div><br>
</div>
<div>Perhaps I should try memkind calls since they may become much better.</div></div></div></blockquote><div><br></div><div>The hbw_malloc() stuff is all just a wrapper for memkind.  I'd suggest going ahead and using the slightly more complicated but more general memkind interface.  We'll need to be using something like memkind, anyway, when we get machines that have even more "kinds" of memory.  (Sorry, it will happen: nonvolatile RAM technologies are coming.  Actually, we already have more than one "kind", as "huge TLB" memory is a supported kind.)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div><br>
</div>
<div>Hong (Mr.)</div><span class="">
<br>
<blockquote type="cite">
<div><br style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<blockquote type="cite" style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>
What is interesting is that hbw_malloc() in memkind can automatically change its allocator to use DRAM if there is insufficient MCDRAM. So I would hope for hbw_free() could change to normal free() when handling data allocated by normal malloc().<br></blockquote></div></blockquote></span></div></div></blockquote><div>As explained above, memkind uses the *same* allocator for both DRAM and MCRAM, it just does the allocation from a different heap partition.  On machines that need memkind, the solution for getting a DRAM allocation should not be to use the normal malloc()/free(), but to use memkind and ask for MEMKIND_DEFAULT instead of MEMKIND_HBW.  memkind_free() will be able to free allocations of either type if you specify a kind of "0".<br><br></div><div>--Richard<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><blockquote type="cite" style="font-family:Verdana;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>
Hong (Mr.)<br>
<br>
<blockquote type="cite"><br>
Sadly, I fear the answer is we don't use memkind because it sucks :-) Calm down Jeff, I didn't insult your mother.<br>
<br>
<br>
<br>
Barry<br>
<br>
<blockquote type="cite">But, as you say, there are issues in other cases, like with -malloc_debug.<br>
<br>
--Richard<br>
<br>
On Thu, Mar 9, 2017 at 4:19 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
Using different mallocs for different objects/arrays in PETSc is very iffy because each free() has to match the malloc used for that memory. This is even true with just -malloc_debug in that certain initialization functions in PETSc need to use the raw malloc()
 because we cannot be sure if the (*PetscTrMalloc)() has been set yet and the raw free() that comes at PetscFinalize() time needs to be matched with it.<br>
<br>
Why not have PetscMalloc() ALWAYS allocate an extra 64 bit space at the beginning and put in an integer indicating the malloc family that has been used to get the space. PetscFree() would use this integer to determine the correct free() to use. A mechanism
 to register new malloc families could be easily done, for example<br>
<br>
 PetscMallocRegister(malloc,<wbr>realloc,free,&basicmalloc);<br>
 PetscMallocRegister(<wbr>PetscMallocDebug,<wbr>PetscReallocDebug,<wbr>PetscFreeDebug,&debugmalloc);<br>
 PetscMallocRegister(<wbr>PetscMallocHBW,<wbr>PetscReallocHBW,PetscFreeHBW,&<wbr>hbwmalloc);<br>
<br>
 To change the malloc used you would do PetscMallocPush(debugmalloc);  PetscMalloc(....); .... PetscMallocPop();  Note that you can register additional malloc families at any time (it doesn't have to be as soon as the program starts up).<br>
<br>
What is wrong with the model and why shouldn't we use it?<br>
<br>
Barry<br>
<br>
Notes:<br>
<br>
It is easy to implement, so that is not a reason.<br>
<br>
The extra memory usage is trivial.<br>
<br>
The mapping from integer to malloc() or free() would be a bounds check and then accessing the function pointer from a little array so pretty cheap.<br>
<br>
if certain mallocs are missing (like PetscMallocHBW) the hbwmalloc variable could be set to the basicmalloc value (or some other) so one would not need to ifdef if if () code deciding which malloc to use in many places.<br>
<br>
It seems so simple something must be fundamentally flawed with it. Even with just PetscTrMallocDefault() and PetscMallocAlign() I feel like implementing it.</blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
</span></div>
<br>
</div>

</blockquote></div><br></div></div>