public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Adhemerval Zanella <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, 3 May 2023 12:42:59 +0000	[thread overview]
Message-ID: <PAWPR08MB898247FC521C64D1C44974C0836C9@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20230420172436.2013698-1-adhemerval.zanella@linaro.org>

Hi Adhemerval,

> +static __always_inline int
> +advise_thp (void *mem, size_t size, char *guard)
> +{
> +  enum malloc_thp_mode_t thpmode = __malloc_thp_mode ();
> +  if (thpmode != malloc_thp_mode_always)
> +    return 0;
> +
> +  unsigned long int thpsize = __malloc_default_thp_pagesize ();
> +  if (PTR_ALIGN_DOWN (mem, thpsize) != PTR_ALIGN_DOWN (guard, thpsize))
> +    return 0;
> +
> +  return __madvise (mem, size, MADV_NOHUGEPAGE);
> +}

This still doesn't make sense since if _STACK_GROWS_DOWN, mem == guard, so
this will always execute the madvise. As I mentioned, I couldn't find evidence that
the claimed scenario of a huge page allocated, written to and then split due to the
mprotect exists.

So the real issue is that the current stack allocation code randomly (based on
alignment from previous mmap calls) uses huge pages even for small stacks.

Cheers,
Wilco

  reply	other threads:[~2023-05-03 12:43 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 [this message]
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
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=PAWPR08MB898247FC521C64D1C44974C0836C9@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).