From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
Cupertino Miranda <cupertino.miranda@oracle.com>
Subject: Re: [PATCH] nptl: Disable THP on thread stack if it incurs in large RSS usage
Date: Wed, 17 May 2023 18:16:40 +0000 [thread overview]
Message-ID: <PAWPR08MB898267578AD700F7B13525F1837E9@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <f23df62c-d13a-fbfa-0fd3-9464c983ab4d@linaro.org>
Hi Adhemerval,
> But the threads themselves do not end up using all the VMA region allocated
> for them. Using the test program you can see it:
Obviously that is due to there being a 2MB gap between each stack. After the
huge page there is a default page for the guard and then empty space for the
alignment till the next stack.
> So even if the stack is not aligned to default large page, THP will still
> back up the thread allocation.
THP can only be used if the mmap covers an aligned huge page. If you
allocate lots of 2MB stacks then you get threads * guardsize / 2MB number
of huge pages since some stacks will become aligned.
>The issues is, if the mmap is also aligned
> to THP size, the guard setup will trigger the issue that will increase RSS.
No it won't. If it is aligned it will get a huge page, and the guard will be before
the huge page (since we allocate 2MB + guardsize).
> This seems to be same conclusion OpenJVM and some kernel discussion has
> reached as well [1] [2].
If that is what they claim, they are wrong. This is not how THP or our stack
allocation works. You can see the allocation of the THP and guard pages
if you print the smaps (build with -DPRINT_PROC_SMAPS).
Cheers,
Wilco
next prev parent reply other threads:[~2023-05-17 18:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 17:24 Adhemerval Zanella
2023-05-03 12:42 ` Wilco Dijkstra
2023-05-15 17:57 ` Adhemerval Zanella Netto
2023-05-16 15:38 ` Wilco Dijkstra
2023-05-16 16:35 ` Adhemerval Zanella Netto
2023-05-17 12:49 ` Wilco Dijkstra
2023-05-17 13:12 ` Cupertino Miranda
2023-05-17 13:20 ` Adhemerval Zanella Netto
2023-05-17 14:22 ` Wilco Dijkstra
2023-05-17 16:50 ` Adhemerval Zanella Netto
2023-05-17 18:16 ` Wilco Dijkstra [this message]
2023-05-18 13:04 ` Adhemerval Zanella Netto
2023-05-23 9:48 ` Wilco Dijkstra
2024-01-31 2:03 ` Cristian Rodríguez
2024-01-31 7:54 ` Florian Weimer
2024-01-31 11:30 ` Adhemerval Zanella Netto
2024-01-31 11:43 ` Florian Weimer
2024-03-12 0:55 ` Cristian Rodríguez
2024-01-31 15:18 ` Cristian Rodríguez
2024-02-01 1:26 ` Cristian Rodríguez
2023-05-16 14:30 ` Cupertino Miranda
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=PAWPR08MB898267578AD700F7B13525F1837E9@PAWPR08MB8982.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=adhemerval.zanella@linaro.org \
--cc=cupertino.miranda@oracle.com \
--cc=libc-alpha@sourceware.org \
/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).