On Sat, Nov 30, 2024 at 05:24:13PM +0100, Dmitry Dolgov wrote: > Hi, > > While working on PostgreSQL [1] we've stumbled upon a question regarding > resizing of shared mappings without conflicting with any other possible > mappings. Before making any wrong conclusions, I would love to get some > consultation from kernel folks on that topic. > > To put it into a context, PostgreSQL uses anonymous shared memory > mapping as a buffer cache for data. The mapping size is configured at > the start, and could not be changed without a restart. Now, we would > like to make it more flexible and allow to change it at runtime, ideally > without changing already used addresses and copying stuff back and > forth. > > The idea is to place the shared mapping at a specified address (with > MAP_FIXED if needed) with a gap, then use mremap to resize it into the > gap. This approach has an open question -- how to make sure there will > be no other mapping created withing the same address space, where we > want to expand the shared mapping? E.g. the shared mapping was created, > then large memory allocation caused another mapping to be created close > to it, so that expanding is not possible. I think there's a very straightforward answer, which is to mmap() it to the larger size to begin with. If, say, you create a file of 1GB, you can mmap() the first 100GB of that file. If you access the last 99GB of the mapping, you'll get SIGBUS, but you can truncate() the file larger and gain access to the new memory that way. Does that work for you? Or if you're doing MAP_ANON | MAP_SHARED, just don't access the last 99GB until your configuration changes. Memory is allocated on demand, so you won't be charged for it until you use it.
