From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: liudongyun <liu.dongyun@h3c.com>, libc-alpha@sourceware.org
Cc: libc-locales@sourceware.org, libc-maintainers@gnu.org,
deng.hongjie@h3c.com, dai.xianjun@h3c.com
Subject: Re: [PATCH] release all idle heaps in the non-main-arena
Date: Fri, 11 Jun 2021 12:11:45 +0530 [thread overview]
Message-ID: <06d6723d-3209-c957-b855-8cc9b0bdbbe4@gotplt.org> (raw)
In-Reply-To: <20210611040852.21745-1-liu.dongyun@h3c.com>
On 6/11/21 9:38 AM, liudongyun wrote:
> liu.dongyun@h3c.com report this question in follow:
> The system has a total of 32G memory and 12 core cpu.
> After frequent malloc and free memory by multiple threads, we found that many
> physical memory that should have been released have not been released.We observe that
> the maximum free memory can reach 15G.
>
> deng.hongjie@h3c.com recommend reducing the heap size of the non-main-arena, but it
> doesn't work. liu.dongyun@h3c.com found When the last heap in the user process into
> the non-main-area has memory in use, the previous heap will not be released, even if the
> previous heap is already free. This mechanism resulting in the memory cache reaching 15G.
Does that cause any actual performance degradation or any other issues
though? heap_shrink() calls madvise (MADV_DONTNEED) on the free parts
of the heap to tell the kernel that the blocks are not needed, so a
fully freed heap ought to not have any performance impact. The RSS
footprint will depend on when the kernel reclaims those pages, which may
not be immediate since madvise is just a hint.
Alternatively, if you disable memory overcommit by setting
/proc/sys/vm/overcommit_memory to 2, heap_shrink() will drop all
permissions on the heap with mprotect(PROT_NONE) instead of doing
madvise. This has a more immediate effect on RSS usage unlike madvise.
Siddhesh
next prev parent reply other threads:[~2021-06-11 6:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 4:08 liudongyun
2021-06-11 6:41 ` Siddhesh Poyarekar [this message]
2021-06-18 8:02 ` 答复: " Liudongyun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06d6723d-3209-c957-b855-8cc9b0bdbbe4@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=dai.xianjun@h3c.com \
--cc=deng.hongjie@h3c.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-locales@sourceware.org \
--cc=libc-maintainers@gnu.org \
--cc=liu.dongyun@h3c.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).