virtual address space allocation

[Babis Chalios]

On 08/01/2018 10:15 PM, valdis.kletnieks at vt.edu wrote:
> On Tue, 31 Jul 2018 15:41:28 +0200, Babis Chalios said:
>
>> I am working on the runtime system of a distributed memory programming
>> language. For some reason we need to create a big hole on the address space of
>> the application. We are trying to do so by using an mmap during the
>> initialization of the runtime and then the runtime handles itself those
>> addresses.
> How big a big hole, exactly?  And when you say "For some reason", does that
> mean "For reasons I don't understand", or "For reasons I don't want to explain"?
> (Note that in American colloquial English, it usually means the first...)
In this case it's the second case :) It's not that I don't want to
explain, I just thought
it was not necessary in that case.

>> However, we do have problems if memory overcommitment is disabled.
> Well, if your "big hole" plus everything already running is big enough to not
> fit in (RAM+SWAP), and you disable overcommit, you're going to have a bad
> day....
I know, that's why I m looking for alternatives.

>
>> So here goes the question: Is there any other mechanism to allow us to
>> do what we want to?
> It's unclear what you're trying to *do*.  Trying to re-invent MPI?  If your
> goal is RDMA, there's already drivers available for Infiniband and other
> fabrics.

Indeed, I am sort of trying to re-invent MPI. So what I didn't explain
before (the "for some reason" part), is that
I d like to abstract MPI from the programmer using our programming
model. I'd like to be able to have the "same"
address space in distributed nodes. So I 'd like to pre-allocate it and
then manage it by myself. The reason for doing
so is that it would let me avoid address translation when I send data over.

Cheers,
Babis

>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180802/09c62f4e/attachment.sig>