zhemao / rmem-server

Remote memory pool over infiniband RDMA
5 stars 1 forks source link

Merge fix_rvm #1

Closed jcarreira closed 9 years ago

jcarreira commented 9 years ago

Request to merge fix_rvm.

Main changes: 1) Support for allocations of different sizes 2) Freed blocks are actually freed from block table 3) Commit functionality 4) RVM layer does not need to know about remote addresses (just about tags) - this required some small changes to the rmem layer

All the tests seem to be passing (except for the big test commit, needs to be checked)

zhemao commented 9 years ago

I should have mentioned this earlier, but I had already implemented a list and hash table data structure for rmem.c. It seems you've re-implemented them yourself here. We might want to consider merging them.

jcarreira commented 9 years ago

Yes, I saw there was a list and hash implementation. I didn't use them because they were mingled with other code.

Yes, that should be refactored.

NathanTP commented 9 years ago

Why are there problems with C11/99?

On Fri, Apr 24, 2015 at 12:10 PM, João Carreira notifications@github.com wrote:

Yes, I saw there was a list and hash implementation. I didn't use them because they were mingled with other code.

Yes, that should be refactored.

— Reply to this email directly or view it on GitHub https://github.com/zhemao/rmem-server/pull/1#issuecomment-96038950.

Nathan Pemberton

jcarreira commented 9 years ago

-std=c11 breaks the code in a bunch of places, but -std=gnu11 seems to work well. Will fix that.

NathanTP commented 9 years ago

Now that I think about it, I tried c11 first and then had to switch to gnu. The problem is that stuff like getopt are actually gnu extensions and are only defined in GNU's version of unistd.h.

On Fri, Apr 24, 2015 at 12:15 PM, João Carreira notifications@github.com wrote:

-std=c11 breaks the code in a bunch of places, but -std=gnu11 seems to work well. Will fix that.

— Reply to this email directly or view it on GitHub https://github.com/zhemao/rmem-server/pull/1#issuecomment-96039776.

Nathan Pemberton