<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 9:46 AM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, 18 Aug 2014 08:15:12 -0700, "Kevin O'Gorman" said:<br>
<br>
> maybe someone here can help me figure out how to map a big (really big)<br>
> work area and lock it in memory.<br>
<br>
</div>What problem are you trying to solve by doing this? It usually doesn't make<br>
sense to lock more than a small chunk in memory - that's mostly for crypto<br>
programs like PGP that are paranoid about keys being written to swap spaces,<br>
and a *very* few highly performance oriented programs. 99.8% of the time,<br>
the kernel will do a reasonable job of making sure the right pages are in<br>
memory.<br>
<br>
Plus, programmers almost always over-estimate what they *really* need to lock<br>
down. The end result is that performance ends up being *worse*, because they<br>
lock out more than needed, leaving all the rest of the processes on the system<br>
fighting over a too-small pool of pages. Really sucks when you actually have<br>
to read from disk every I/O because you no longer have an in-core file cache :)<br>
<div><br></div></blockquote><div>I'm solving a huge alpha-beta search problem, and want a huge cache table tocheck permutations. That's why I increased RAM from 8 to 32 GB, and would<br>be happy to use the extra 24GB all for the cache. (Cache table is like a hash table but with collisions causing replacement rather than chaining).<br>
<br></div><div>Even in my small tests, the cache is giving me speedups in the neighborhood of<br></div><div>a million, so I'm going big. Because this is about speed, I do not *ever* want it to<br></div><div>swap.<br></div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> I wrote a little test program to try this out, and it fails. As a regular<br>
> user, perror() tells me some "resource is temporarily unavailable". As<br>
> root, it says it "cannot allocate memory". I'm only asking for 1 byte.<br>
<br>
</div><div class="">> where = mmap(NULL, length, PROT_READ | PROT_WRITE, MAP_PRIVATE |<br>
> MAP_ANONYMOUS | MAP_HUGETLB | MAP_LOCKED | MAP_POPULATE, -1, 0);<br>
<br>
</div>Remember that no matter what "length" you pass, even if it's 1 byte, the<br>
kernel has to allocate at least enough integer pages to cover the request.<br>
You ask for 4100 bytes, it has to allocate 2 pages because 4096 isn't<br>
quite big enough.<br>
<br>
And if you ask for MAP_HUGETLB, you're going to get at least 1 page. Which<br>
is probably 2M in size. And that can be painful if the default max lockable<br>
memory is less than 2M (at least on my Fedora Rawhide box, it's all of<br>
64K). There's also some interaction danger with MAP_POPULATE and memory<br>
fragmentation. But both POPULATE and HUGETLB have a high chance of<br>
not playing well with LOCKED.<br>
</blockquote></div><br></div><div class="gmail_extra">Good catch. Indeed, removing MAP_HUGETLB allows the program to succeed. I'll try increasing the resource limit, but may have to have to sudo it, do the mmap() and then chusr to my real ID.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">The fd of -1 that some folks thought might be a problem is suggested in the man page for use with MAP_ANONYMOUS. That flag means I'm not using a backing file, after all.<br clear="all">
</div><div class="gmail_extra"><br>-- <br><div dir="ltr">Kevin O'Gorman<br><br>programmer, n. an organism that transmutes caffeine into software.<br><span style="line-height:normal;font-variant:normal;font-size:10pt;font-style:normal;font-weight:normal"><span style="line-height:normal;font-variant:normal;font-size:10pt;font-style:normal;font-weight:normal"></span></span><table cellpadding="0" cellspacing="0" border="0" width="448">
<tbody><tr><td width="25"><img src="cid:XVHDKDFDBURW.IMAGE_60.gif" height="21" width="25"></td>
<td width="423"><span style="FONT-FAMILY:Verdana,Geneva,sans-serif;COLOR:rgb(0,153,0);MARGIN-LEFT:5px;FONT-SIZE:10px">Please consider the environment before printing this email.</span></td></tr></tbody></table><br></div>
</div></div>