linux-kernel - Re: THP backed thread stacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230307190233.GA5892@monkey>
Date:   Tue, 7 Mar 2023 11:02:33 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Rik van Riel <riel@...riel.com>
Subject: Re: THP backed thread stacks

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@...riel.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