[petsc-dev] Adding support memkind allocators in PETSc

[Jed Brown]

Jeff Hammond <jeff.science at gmail.com> writes:

> On Wed, Jun 3, 2015 at 9:58 PM, Jed Brown <jed at jedbrown.org> wrote:
>> Jeff Hammond <jeff.science at gmail.com> writes:
>>> The beauty of git/github is one can make branches to try out anything
>>> they want even if Jed thinks that he knows better than Intel how to
>>> write system software for Intel's hardware.
>>
>> I'm objecting to the interface.  I think that if they try to get memkind
>> merged into the existing libnuma project, they'll see similar
>> resistance.  It is essential for low-level interfaces to create
>> foundations that can be reliably built upon, not gushing wounds that
>> bleed complexity into everything built on top.
>
> Step 1: Commit a change associated with the new interface function.

This response is not germane to my point above.  I also never asked for
a new interface.

> Step 2: Commit a change implementing the new interface function.
> Step 3: File a pull request.
>
>>> This link is equivalent to pushing the "Fork" button on Github's
>>> memkind page: https://github.com/memkind/memkind#fork-destination-box.
>>> I'm sure that the memkind developers would be willing to review your
>>> pull request once you've implemented memkind_move_pages().
>>
>> 1. I cannot test it because I don't have access to the hardware.
>
> The memkind library itself was developed entirely without access to
> the hardware to which you refer, so this complaint is not relevant.

The interesting case here is testing failure modes in the face of
resource exhaustion, which doesn't seem to have been addressed in a
serious way by memkind and requires other trickery to test without
MCDRAM.  Also, the performance effects are relevant.  But I don't want
anything else in memkind because I don't want to use memkind for
anything ever.

>> 2. I think memkind is solving the wrong problem in the wrong way.
>
> It is more correct to say it is solving a different problem than the
> one you care about.  memkind is the correct way to solve the problem
> it is trying to solve.  Please stop equating your disagreement with
> the problem statement as evidence that the solution is terrible.

This is pedantry.  Is there a clear statement of what problem memkind
solves?

  The memkind library is 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.

This is just a low-level statement about what it does and I would argue
it doesn't even do this in a useful way because it is entirely at
allocation time assuming the caller is omniscient.

>> 3. According to Richard, the mature move_pages(2) interface has been
>> implemented.  That's what I wanted, so I'll just use that -- memkind
>> dependency gone.
>
> Does this mean that you will stop complaining about memkind, since it
> is not directly relevant to your life?  I would like that.

Yes, as soon as people stop telling me that I should use memkind and
stop asking to put it into packages I interact with, I'll ignore it like
countless other projects that are irrelevant to what I do.  But if, like
OpenMP, the turd keeps landing in my breakfast, I'm probably going to
mention that it's impolite to keep pooping in my breakfast.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150603/bd827e59/attachment.sig>