Refine memory allocation for MPP Hash Join

For now Allocator will use a MMAP_THRESHOLD to decide if we need to manually do mmap or mremap.

Clickhouse makes the MMAP_THRESHOLD 64MB. And here gives their reason:

mmap/munmap is very slow and does not scale. It gives about 1000 iterations per second regardless the number of threads. Suppose you want to allocate chunk of memory and then fill it with data and process. Let's make this chunk large enough, so the cost of mmap/munmap will be neglible to the cost of data processing. The size 64MB is selected under assumption that we can process data with speed up to several tens of gigabytes per second.

The assumption is that 64 MB is large enough to amortize the cost of page faults. If it's not the case, better to increase the threshold globally.

While in TiFlash MPP workload, there are massive allocation during Hash Join build stage because of hashtable rehashing. In this case, page fault will take about 10% of CPU time. Here's an example of TPCH 100 Q9:

We found that if we tune up the threshold value to a higher value like 64GB, page fault will reduce a lot:

Start with the Allocator and its MMAP_THRESHOLD decision, then examine memory allocation during the MPP Hash Join build stage. Reproduce or profile the TPCH 100 Q9 workload described in the issue and compare page-fault CPU time. Done means the allocation threshold is refined and page faults are substantially reduced for this workload.