> all the possible scenarios. But now I'm reworking it along the lines suggested
> by Thomas, and will address those as well. Thanks!
Thanks for the info, Dmitry.
Just want to confirm my understanding of Thomas' suggestion and your discussions... I think the simpler and more
portablesolution goes something like the following?
* For each BP resource segment (main, desc, buffers, etc):
1. create an anonymous file as backing
2. mmap a large reserved shared memory area with PROTO_READ/WRITE + MAP_NORESERVE using the anon fd
3. use ftruncate to back the in-use region (and maybe posix_fallocate too to avoid SIGBUS on alloc failure during
first-touch),but no need to create a memory mapping for it
4. also no need to create a separate mapping for the reserved region (already covered by the mapping created in 2.)
|-- Memory mapping (MAP_NORESERVE) for BUFFER --|
|-- In-use region --|----- Reserved region -----|
* During resize, simply calculate the new size and call ftruncate on each segment to adjust memory accordingly, no need
tommap/munmap or modify any memory mapping.
I tried this approach with a test program (with huge pages), and both expand and shrink seem to work as expected --for
shrink,the memory is freed right after the resize ftruncate.
Regards,
Jack Ng
