<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 10:32 AM, Yann Droneaud <span dir="ltr">&lt;<a href="mailto:ydroneaud@opteya.com" target="_blank">ydroneaud@opteya.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Le mardi 06 octobre 2015 à 10:13 -0400, Kenneth Adam Miller a écrit :<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Oct 6, 2015 at 9:58 AM, Yann Droneaud &lt;<a href="mailto:ydroneaud@opteya.com">ydroneaud@opteya.com</a>&gt;<br>
&gt; wrote:<br>
&gt; &gt; Le mardi 06 octobre 2015 à 09:26 -0400, Kenneth Adam Miller a écrit<br>
&gt; &gt; :<br>
&gt; &gt;<br>
&gt; &gt; &gt; Any body know about the issue of assigning a process a region of<br>
&gt; &gt; &gt; physical memory to use for it&#39;s malloc and free? I&#39;d like to just<br>
&gt; &gt; &gt; have the process call through to a UIO driver with an ioctl, and<br>
&gt; &gt; then<br>
&gt; &gt; &gt; once that&#39;s done it gets all it&#39;s memory from a specific region.<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; You mean CONFIG_UIO_DMEM_GENIRQ (drivers/uio/uio_dmem_genirq.c)<br>
&gt; &gt;<br>
&gt; &gt; See:<br>
&gt; &gt; <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm" rel="noreferrer" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm</a><br>
&gt; &gt; it/?id=0a0c3b5a24bd802b1ebbf99e0b01296647b8199b<br>
&gt; &gt; <a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm" rel="noreferrer" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm</a><br>
&gt; &gt; it/?id=b533a83008c3fb4983c1213276790cacd39b518f<br>
&gt; &gt; <a href="https://www.kernel.org/doc/htmldocs/uio-howto/using-uio_dmem_genirq" rel="noreferrer" target="_blank">https://www.kernel.org/doc/htmldocs/uio-howto/using-uio_dmem_genirq</a><br>
&gt; &gt; .html<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; Well I don&#39;t think that does exactly what I would like, although I&#39;ve<br>
&gt; got that on my machine and I&#39;ve been compiling it and learning from<br>
&gt; it. Here&#39;s my understanding of the process of the way mmap works:<br>
&gt;<br>
&gt; Mmap is called from userland and it maps a region of memory of a<br>
&gt; certain size according to the parameters given to it, and the return<br>
&gt; value it has is the address at which the block requested starts, if<br>
&gt; it was successful (which I&#39;m not addressing the unsuccessful case<br>
&gt; here for brevity). The userland process now has only a pointer to a<br>
&gt; region of space, as if they had allocated something with new or<br>
&gt; malloc. Further calls to new or malloc don&#39;t mean that the pointers<br>
&gt; returned will preside within the new mmap&#39;d chunk, they are just<br>
&gt; separate regions also mapped into the process.<br>
&gt;<br>
<br>
</div></div>You have to write your own custom allocator using the mmap()&#39;ed memory<br>
your retrieved from UIO.<br></blockquote><div><br></div><div>I know about C++&#39;s placement new. But I&#39;d prefer to not have to write my userland code in such a way-I want my userland code to remain agnostic of where it gets the memory from. I just want to put a small prologue in my main, and then have the rest of the program oblivious to the change.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt; What I would like is a region of memory that, once mapped to a<br>
&gt; process, further calls to new/malloc return pointers that preside<br>
&gt; within this chunk. Calls to new/malloc and delete/free only edit the<br>
&gt; process&#39;s internal table, which is fine.<br>
&gt;<br>
&gt; Is that wrong? Or is it that mmap already does the latter?<br>
<br>
</span>It&#39;s likely wrong. glibc&#39;s malloc() using brk() and mmap() to allocate<br>
anonymous pages. Tricking this implementation to use another mean to<br>
retrieve memory is left to the reader.<br>
<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, are you sure you want any random calls to malloc() (from glibc<br>
itself or any other linked-in libraries) to eat UIO allocated buffers ?<br>
I don&#39;t think so: such physically contiguous, cache coherent buffers<br>
are premium ressources, you don&#39;t want to distribute them gratuitously.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Yes - we have a hard limit on memory for our processes, and if they try to use more than what we mmap to them, they die, and we&#39;re more than fine with that. In fact, that&#39;s part of our use case and model, we&#39;ve planned to allocate just 5 or so processes on our behemoth machine with gigabytes of memory. So they aren&#39;t so premium to us. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
Regards.<br>
<br>
--<br>
Yann Droneaud<br>
OPTEYA<br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>