Why I can't map memory with mmap

[Valdis.Kletnieks at vt.edu]

On Mon, 18 Aug 2014 10:24:45 -0700, you said:
> 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
> 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).
>
> Even in my small tests, the cache is giving me speedups in the neighborhood of
> a million, so I'm going big. Because this is about speed, I do not *ever*
> want it to swap.

Throwing another 24G at that sort of program is probably a Good Idea(tm)
(although I'd check how much better your hit ratio is at 8G and 32G.

However, locking it into memory isn't always obviously a good idea - the
problem is that it's *way* too easy to overcommit locked memory and end up
starving the rest of the system to the point where your overall performance
actually drops.  And if you're actually hitting all the pages, and have
enough RAM, they *will* stay in memory anyhow. (And 98% of the time, the
delay in paging in a swapped-out page was more than made up for by the
time savings in having whatever pages *was* resident).

Oh, and don't forget that if you use MAP_POPULATE, you pay the costs of
populating that page (and evicting whatever used to be there) *even if
you never actually use the page*.  So make damned sure you have a really good
hash function that hits all the buckets (this is often harder to do than
it looks, especially for very large numbers of buckets).

We have a Honking Big box across the hall - SGI UV, 504 cores, 2.7T of RAM,
and one of the *fastest* ways to bring it to a screeching halt was locking the
wrong 8G of stuff into RAM.  Yes, you can find a corner case where locking
only 0.3% of the RAM will panic the box.  NUMA memory allocations can be
*so* much fun... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140818/ef582865/attachment-0001.bin