All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Peter Xu <peterx@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Rik van Riel <riel@surriel.com>, Mike Rapoport <rppt@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: THP backed thread stacks
Date: Wed, 8 Mar 2023 11:02:06 -0800	[thread overview]
Message-ID: <20230308190206.GA4005@monkey> (raw)
In-Reply-To: <20230307004049.GC4956@monkey>

On 03/06/23 16:40, Mike Kravetz wrote:
> On 03/06/23 19:15, Peter Xu wrote:
> > On Mon, Mar 06, 2023 at 03:57:30PM -0800, Mike Kravetz wrote:
> > > 
> > > Just wondering if there is anything better or more selective that can be
> > > done?  Does it make sense to have THP backed stacks by default?  If not,
> > > who would be best at disabling?  A couple thoughts:
> > > - The kernel could disable huge pages on stacks.  libpthread/glibc pass
> > >   the unused flag MAP_STACK.  We could key off this and disable huge pages.
> > >   However, I'm sure there is somebody somewhere today that is getting better
> > >   performance because they have huge pages backing their stacks.
> > > - We could push this to glibc/libpthreads and have them use
> > >   MADV_NOHUGEPAGE on thread stacks.  However, this also has the potential
> > >   of regressing performance if somebody somewhere is getting better
> > >   performance due to huge pages.
> > 
> > Yes it seems it's always not safe to change a default behavior to me.
> > 
> > For stack I really can't tell why it must be different here.  I assume the
> > problem is the wasted space and it exaggerates easily with N-threads.  But
> > IIUC it'll be the same as thp to normal memories iiuc, e.g., there can be a
> > per-thread mmap() of 2MB even if only 4K is used each, then if such mmap()
> > is populated by THP for each thread there'll also be a huge waste.

I may be alone in my thinking here, but it seems that stacks by their nature
are not generally good candidates for huge pages.  I am just thinking about
the 'normal' use case where stacks contain local function data and arguments.
Am I missing something, or are huge pages really a benefit here?

Of course, I can imagine some thread with a large amount of frequently
accessed data allocated on it's stack which could benefit from huge
pages.  But, this seems to be an exception rather than the rule.

I understand the argument that THP always means always and everywhere.
It just seems that thread stacks may be 'special enough' to consider
disabling by default.
-- 
Mike Kravetz


  reply	other threads:[~2023-03-08 19:02 UTC|newest]

Thread overview: 23+ 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 [this message]
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
2023-03-12  0:55                   ` Hillf Danton
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
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=20230308190206.GA4005@monkey \
    --to=mike.kravetz@oracle.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.