Re: Changing shared_buffers without restart

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 <9erthalion6(at)gmail(dot)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.
>