I agree that it doesn't matter what value of
n you specify for
dbcache=n, even when I don't exactly know how Bitcoin Core actually allocates memory for such caches.
But 4 KiB pages aren't the only size that most CPU and OS architectures support. There's usually also something called large or huge pages, because having to manage only a fixed small size like 4 KiB isn't efficient in certain cases.
Maybe have a look here to dig deeper, for those who are interested:
https://en.wikipedia.org/wiki/Page_(computer_memory)we know that most systems use 4 KiB as the default memory page size, but typically of 2 MiB or even of 1 GiB in size, they also support large pages (also called huge pages) large pages reduce overhead of managing many small pages and improve CPU cache efficiency(as u said )
Bitcoin Core does not request explicitly for the use of large pages when allocating memory for dbcache it uses normal memory allocation methods such as malloc and new and it relies on the operating system’s default behavior that uses standard 4 KiB pages bitcoin Core would need to perform special operations in the event that it wanted to use large pages (like mmap with MAP HUGETLB on Linux, or VirtualAlloc with MEM_LARGE_PAGES on Windows) and mainly due to the fact that it does not
voluminous pages require additional system configuration or admins configure
Certain fragmentation or failure issues can occur when managing a number of large pages this can be caused by managing of large pages in a dynamic way
Bitcoin Core needs to be simple,stable and portable across many of the OSesBitcoin Core will allocate memory in a safe and efficient manner, regardless of the value you set for dbcache=n as a result each integer n that is for dbcache still will align in a neat way to the page system, without any waste or inefficiency, due to 1 MiB = 1,048,576 bytes = 256 × 4 KiB pages, setting dbcache to a value that is divisible by one thousand twentyfour is not at all necessary each integer is perfectly fine