Jeff Hammond <[email protected]> writes: > On Wed, Jun 3, 2015 at 9:58 PM, Jed Brown <[email protected]> wrote: >> Jeff Hammond <[email protected]> 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.
signature.asc
Description: PGP signature
