Dear kernel hackers, 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. This scenario works properly when the system allows memory overcommitment. More specifically, we seem to be fine if the /proc/sys/vm/overcommit_memory contains the values 0 or 1. However, we do have problems if memory overcommitment is disabled. So here goes the question: Is there any other mechanism to allow us to do what we want to? Things I 've thought so far: 1) To do my mmaps using PROT_NONE assuming that maybe those pages are not accounted for when calculating overcommitment. I did some tests and it seems that this assumption is wrong. 2) The possibility that there are addresses that are highly unlikely to be mapped in the address space of my application. If there is such an address range I could potentially relax the requirement that I should map all the address space at the beginning of the execution and instead try to mmap it progressively at runtime on a per-need basis. Any thoughts would be helpful. Cheers, Babis
On 07/31/2018 09:41 AM, Babis Chalios wrote:
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.
Oh ok Allocate more memory -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
On 07/31/2018 09:58 PM, Ruben Safir wrote:
On 07/31/2018 09:41 AM, Babis Chalios wrote:
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.
Oh ok
Allocate more memory
That's really useful, thanks.
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...)
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....
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.
On 08/01/2018 10:15 PM, valdis.kletnieks@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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (3)
-
Babis Chalios -
Ruben Safir -
valdis.kletnieks＠vt.edu