mirror of
https://github.com/HChaZZY/Stockfish.git
synced 2025-12-25 19:46:55 +08:00
Turn on MADV_RANDOM for Syzygy mmaps (on Unix-like builds)
When running on a cloud VM (n1-highcpu-96) with several NVMe SSDs and some non-SSDs for tablebases, I noticed that the average SSD request size was more than 256 kB. This doesn't make a lot of sense for Syzygy tablebases, which have a block size of 32 bytes and very low locality. Seemingly, the tablebase access patterns during probing make the OS, at least Linux, think that readahead is advantageous; normally, it gives up doing readahead if there are too many misses, but it doesn't, perhaps due to the fairly high overall hit rates. (It seems the kernel cannot distinguish between reading a block that was paged in because the userspace wanted it explicitly, and one that was read as part of readahead.) Setting MADV_RANDOM effectively turns off readahead, which causes the request size to drop to 4 kB. In the aforemented cloud VM test, this roughly tripled the amount of I/O requests that were able to go through, while reducing the total traffic from 2.8 GB/sec to 56 MB/sec (moving the bottleneck to the non-SSDs; it seems the SSDs could have sustained many more requests). Closes https://github.com/official-stockfish/Stockfish/pull/1829 No functional change.
This commit is contained in:
committed by
Stéphane Nicolet
parent
6ab92d2e1c
commit
de7182f4ee
@@ -216,6 +216,7 @@ public:
|
||||
fstat(fd, &statbuf);
|
||||
*mapping = statbuf.st_size;
|
||||
*baseAddress = mmap(nullptr, statbuf.st_size, PROT_READ, MAP_SHARED, fd, 0);
|
||||
madvise(*baseAddress, statbuf.st_size, MADV_RANDOM);
|
||||
::close(fd);
|
||||
|
||||
if (*baseAddress == MAP_FAILED) {
|
||||
|
||||
Reference in New Issue
Block a user