Revert "Increase maximum read-only mmap()s used from 1000 to 4096 on 64-bit systems" #52
Conversation
…64-bit systems" After bitcoin/bitcoin#30039, the number of ldb files created is 16 times smaller. 1000 files with the new default of 32MB is 32GB of database. If we need more, we can increase the default file size again. This patch seems unnecessary now. This reverts commit 92ae82c.
There was a problem hiding this comment.
For the record, the change was triggered by one of the synchronization efforts between our fork an the upstream repo google#1265
This revert basically leaves us closer to the original LevelDB implementation - where both env_posix.cc and env_windows.cc have this value, see: https://github.com/search?q=repo%3Agoogle%2Fleveldb%20kDefaultMmapLimit&type=code
ACK fd8f696
| // Up to 4096 mmap regions for 64-bit binaries; none for 32-bit. | ||
| constexpr const int kDefaultMmapLimit = (sizeof(void*) >= 8) ? 4096 : 0; | ||
| // Up to 1000 mmap regions for 64-bit binaries; none for 32-bit. | ||
| constexpr const int kDefaultMmapLimit = (sizeof(void*) >= 8) ? 1000 : 0; |
There was a problem hiding this comment.
+1, this matches upstream and the current the env_windows.cc version
|
Yes, the motivation here is to limit the amount of divergence from upstream leveldb (especially patches they are extremely unlikely to merge), though this is a harmless, trivial change, so could also keep it i don't feel strongly about it. #50 is worse. |
|
ACK fd8f696 I'd be in favor of just bumping the max file size if/when we start approaching the mmap limit again. |
After bitcoin/bitcoin#30039, the number of ldb files created is 16 times smaller. 1000 files with the new default of 32MB is 32GB of database.
If we need more (for good performance), we can increase the default file size again.
This patch seems unnecessary now.
This reverts commit 92ae82c: