<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 9, 2017 at 8:37 AM, Eero Tamminen <span dir="ltr"><<a href="mailto:eero.t.tamminen@intel.com" target="_blank">eero.t.tamminen@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">HI,<br>
<br>
On 09.03.2017 13:28, Tapani Pälli wrote:<br>
...<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We had some discussion today with Eero and came to conclusion that maybe<br>
that 2GB is actually too big for 32bit system anyway and should consider<br>
to have even smaller block pool size in this case? Or should I just send<br>
a patch that adds '- 1' to ftruncate call? Opinions?<br>
</blockquote>
<br></span>
Vulkan driver taking 2GB out of application address space, doesn't leave that much for rest of the memory mappings, if the application itself would want to mmap() some large data files.<br></blockquote><div><br></div><div>That's not really what's going on.  We ftruncate the file to 2GB to make sure it's "big enough" but we only mmap a very small portion of it.  Dropping the size to 1GB should be just fine. <br></div></div></div></div>