unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra via Libc-alpha <libc-alpha@sourceware.org>
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 12:49:42 +0000	[thread overview]
Message-ID: <PAWPR08MB898213ECDCF7D98E89370654837E9@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <f0b2fca5-f21d-b538-329f-7795e85ad4f1@linaro.org>

Hi Adhemerval,

>> The question is, under what circumstances are huge pages in stacks beneficial and
>> in which cases are they not? If have a good answer to that, then we can automatically
>> do the right thing without needing a tuning.
>> 
> 
> Afaiu the issue is not whether huge page in stacks is beneficial, but rather 
> when kernel will fall back to default pages anyway which will be just waste 
> cycles.  Another option would be tune the default stack and guard size
> to avoid this issue, but this might require some more heuristics to find a 
> good spot to avoid too much VMA waste.

The kernel won't fallback to standard pages - like I said, it really allocates a huge
page when it can (based on alignment of the stack) and that is what causes the
increase of RSS size. But that's not evidence of an issue.

So the real question is when do huge pages make sense for stacks?

Cheers,
Wilco

  reply	other threads:[~2023-05-17 12:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-20 17:24 [PATCH] nptl: Disable THP on thread stack if it incurs in large RSS usage Adhemerval Zanella via Libc-alpha
2023-05-03 12:42 ` Wilco Dijkstra via Libc-alpha
2023-05-15 17:57   ` Adhemerval Zanella Netto via Libc-alpha
2023-05-16 15:38     ` Wilco Dijkstra via Libc-alpha
2023-05-16 16:35       ` Adhemerval Zanella Netto via Libc-alpha
2023-05-17 12:49         ` Wilco Dijkstra via Libc-alpha [this message]
2023-05-17 13:12           ` Cupertino Miranda via Libc-alpha
2023-05-17 13:20           ` Adhemerval Zanella Netto via Libc-alpha
2023-05-17 14:22             ` Wilco Dijkstra via Libc-alpha
2023-05-17 16:50               ` Adhemerval Zanella Netto via Libc-alpha
2023-05-17 18:16                 ` Wilco Dijkstra via Libc-alpha
2023-05-18 13:04                   ` Adhemerval Zanella Netto via Libc-alpha
2023-05-23  9:48                     ` Wilco Dijkstra via Libc-alpha
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 via Libc-alpha

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

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PAWPR08MB898213ECDCF7D98E89370654837E9@PAWPR08MB8982.eurprd08.prod.outlook.com \
    --to=libc-alpha@sourceware.org \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=cupertino.miranda@oracle.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).