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... :)