You're right Dmitry, truncating the anonymous file before mapping it again does the trick! I see 'HugePages_Free' increases to the expected size right after the ftruncate call for shrinking. This alternative approach looks very promising. Thanks.
Regards, Jack Ng On Fri, Mar 21, 2025 at 5:31 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Fri, Mar 21, 2025 at 04:48:30PM GMT, Ni Ku wrote: > > Thanks for your insights and confirmation, Dmitry. > > Right, I think the anonymous fd approach would work to keep the memory > > contents intact in between munmap and mmap with the new size, so > bufferpool > > expansion would work. > > But it seems shrinking would still be problematic, since that approach > > requires the anonymous fd to remain open (for memory content protection), > > and so munmap would not release the memory back to the OS right away > (gets > > released when the fd is closed). From testing this is true for hugepage > > memory at least. > > Is there a way around this? Or maybe I misunderstood what you have in > mind > > ;) > > The anonymous file will be truncated to it's new shrinked size before > mapping it second time (I think this part is missing in your test > example), to my understanding after a quick look at do_vmi_align_munmap, > this should be enough to make the memory reclaimable. >
