From: Mike Kravetz <mike.kravetz@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Rik van Riel <riel@surriel.com>
Subject: Re: THP backed thread stacks
Date: Tue, 7 Mar 2023 11:02:33 -0800 [thread overview]
Message-ID: <20230307190233.GA5892@monkey> (raw)
In-Reply-To: <278ec047-4c5d-ab71-de36-094dbed4067c@redhat.com>
On 03/07/23 11:10, David Hildenbrand wrote:
> On 07.03.23 00:57, Mike Kravetz wrote:
> > One of our product teams recently experienced 'memory bloat' in their
> > environment. The application in this environment is the JVM which
> > creates hundreds of threads. Threads are ultimately created via
> > pthread_create which also creates the thread stacks. pthread attributes
> > are modified so that stacks are 2MB in size. It just so happens that
> > due to allocation patterns, all their stacks are at 2MB boundaries.
>
> Is this also related to a recent change, where we try to always align at PMD
> boundaries now, such that this gets more likely?
Nope, it happens on a kernel without this change.
> commit f35b5d7d676e59e401690b678cd3cfec5e785c23
> Author: Rik van Riel <riel@surriel.com>
> Date: Tue Aug 9 14:24:57 2022 -0400
>
> mm: align larger anonymous mappings on THP boundaries
>
>
> As a side note, I even heard of complains about memory bloat when switching
> from 4k -> 64k page size with many threads ...
It seems like the 'answer' is to have applications explicitly opt out of
THP if they know it is detrimental for some reason. In this case, it
makes sense to opt out for thread stacks that are known to be 2MB at most.
Unfortunately, this means the application would need to replicate stack
creation (including guard pages) as well as cleanup that is done in
libpthread/glibc.
--
Mike Kravetz
next prev parent reply other threads:[~2023-03-07 19:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 23:57 THP backed thread stacks Mike Kravetz
2023-03-07 0:15 ` Peter Xu
2023-03-07 0:40 ` Mike Kravetz
2023-03-08 19:02 ` Mike Kravetz
2023-03-09 22:38 ` Zach O'Keefe
2023-03-09 23:33 ` Mike Kravetz
2023-03-10 0:05 ` Zach O'Keefe
2023-03-10 1:40 ` William Kucharski
2023-03-10 11:25 ` David Hildenbrand
2023-03-11 12:24 ` William Kucharski
[not found] ` <20230312005549.2609-1-hdanton@sina.com>
2023-03-12 4:39 ` William Kucharski
2023-03-10 22:02 ` Yang Shi
2023-03-07 10:10 ` David Hildenbrand
2023-03-07 19:02 ` Mike Kravetz [this message]
2023-03-07 13:36 ` Mike Rapoport
2023-03-17 17:52 ` Matthew Wilcox
2023-03-17 18:46 ` Mike Kravetz
2023-03-20 11:12 ` David Hildenbrand
2023-03-20 17:46 ` William Kucharski
2023-03-20 17:52 ` David Hildenbrand
2023-03-20 18:06 ` Mike Kravetz
2023-03-18 12:58 ` David Laight
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=20230307190233.GA5892@monkey \
--to=mike.kravetz@oracle.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.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 NNTP newsgroup(s).