Date:   Mon, 6 Mar 2023 16:40:49 -0800
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Peter Xu <peterx@redhat.com>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: THP backed thread stacks
Message-ID: <20230307004049.GC4956@monkey>
References: <20230306235730.GA31451@monkey>
 <ZAaCISgq4A/GnkCk@x1n>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZAaCISgq4A/GnkCk@x1n>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?B2iUbMROQgBxhjyg6/9WC9/wLPHe8cKp0SH/Y6o3DOnnFDJ8eahr9P22wz9P?=
 =?us-ascii?Q?8f6kGbEXucV7o/8BK8h/sTGNUlIPuyGkaVd8HPtbyvpL1pasXcF+OKetQ/oP?=
 =?us-ascii?Q?9s0xRB7MnbUa+jz26B0k6WFah0ivkRRsG+BSGXsTLtN5+8hTyLpbPnN3pZe6?=
 =?us-ascii?Q?jmY4UyGBXTroQXrfGat9q/JRPQyj9qRXNv21BXlKCKU3qFgW+cl19AWZ4wq7?=
 =?us-ascii?Q?f3spsxP+8owwWdOk1ysuqHmgYqy6uQmo6/HYK2NZG1Rw3b4dPXChD2gYq4AZ?=
 =?us-ascii?Q?1nmM6Vm8PX4GZokVYNPN/E7/fiZZZmLtx2plCur2Tn43oQLlllf5U+uXjIv6?=
 =?us-ascii?Q?SBgKRow6h9f23peA8sRQ3Ta2Fgto7tkiE301y4fj8BHl409NO3BDAtV5jukt?=
 =?us-ascii?Q?z/VdRN3P4G+RCWeuwEpRaxea1J6qQWBRQS1ttTjcfyxSp2tMrc8sQ2RVDjwW?=
 =?us-ascii?Q?weO1JW06xzSvmXaXhugO7pKdNZh54J7cfCPzF1gF2cgKM9zS8VGW45lAbhP4?=
 =?us-ascii?Q?IW6subscXfRxlheHEbLRz+k/Yv8vH/wyck+suzH83Ren/JGyVL/3z3UrU47M?=
 =?us-ascii?Q?oivm0kZ2DAmuE8xJbplvCvHOcldFqFSifT70Ixy4oaSJOTjNg5gy7UAEa2BB?=
 =?us-ascii?Q?4cvdnPj6BduVXMvxmIOvW0IwWm+GJbJBTKocasIN/gRNFdzbvrBnBCfHR9pW?=
 =?us-ascii?Q?M/Ylj7qBMb7cgvJ13+Va9oh3UpZxebPwZyH0F+qd24rsSiIZC6SooF1mdlXJ?=
 =?us-ascii?Q?7cLanc+CdpwoXypYnNcVPL6XXcaVAkG0UHxIvc+/6KpS4G5Zk2it2LqNFFkr?=
 =?us-ascii?Q?S2Af93nfeOcSOjnY8c0w+5f0doi4J6skGhuUv0h5yg14pIf7mlUduj1lS0Hc?=
 =?us-ascii?Q?S4TwM9PYIEUOSiEGLo5v0UxZHiSqI0+WuKJMSzG+KXUM5ExlR3kShCLLPWcN?=
 =?us-ascii?Q?o7jjGbDIkUJKSUvjb9uhfsaDxzEQyjI/8Zqd6g2tUSh/V5+cLEXIwvurRTVo?=
 =?us-ascii?Q?AOSz26sG7BN/xjfAUp/hvoKYGgCJ5X5seokQ9hP2EKJdTvEPoscNsMdK0EEq?=
 =?us-ascii?Q?fpZaGYy/sOSSbxG+N4N2jA4BsGt5PM5hNcNflQdAXsA9NUmo81zyRUpSJQfZ?=
 =?us-ascii?Q?LHfwNKIjHErsCqb6BRNTIlHeqQniH3N1h9EfFGHei1TQlyHCYk5OkliZ3dQh?=
 =?us-ascii?Q?sPZFTXYHXEu0DI/Zc756Bw9m9QnjHpxniMXPNcl2aSBoUw0mxFtZhhkpANv9?=
 =?us-ascii?Q?6YOQLDlSsdzXc+fDhLtxr+8sv8GOui/Pnxjc479iMWaMfWGd5HvFc6ZDIxMR?=
 =?us-ascii?Q?nbrMfHk/DSHrHeWFPcqJ9XvFYpKOCG7EBfzzB8AwLqxXojVUc8Q8gNsl7++T?=
 =?us-ascii?Q?fXs+Mikmcbr9QSs/22RvqKS18p++4bGnqU6tPe11cVJfxcJQUFLTv2h8Axv1?=
 =?us-ascii?Q?D6Cx2Rc6cKkc6Wwwo1iKbqmVeJ43IPiztDLVH4PlTvDGfEHcc1QHSAUcgdUN?=
 =?us-ascii?Q?GvuIQpH64n4TAqFA7DYm8dU4HJRnkjtfqlsNwUZGqu9yFQkzGNykxtymW56P?=
 =?us-ascii?Q?LP4F21CXC4N4F9fCc5C4bbBCoDY2ALFcqwGo2lovh3KB+wOqqO1d+OHTsk/3?=
 =?us-ascii?Q?bA=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: OqPoKix1os04/6KzGDIyraaQMgijEmFX42nD/2rHlyWRGr689pZ3UUD3fzsGuKUMZBjEU+5k//Kup57xmDfBXLuDLBDYm8dGnKb41KRSf32UddcKgEweR6PUelWKr2ynCCSjrBhI/oSj8oStuMJZ2QuIlfZsrg7i90M43LqpSzYhFCGytYyIGdWtfaMEudtTqaS6t46UNnzGP3RCe+oPftPtvMgJTO8038HOoF66jxkIXC+XH41JivxAZxu6sZ7v8LDdo+18J4jsRjiXnztPC8roP8+B89E1LiiCPhugvw0/IqKIpcVSaGN/31rRCq9KXdcLYQKw7G8CzYcMGkEfLY8Dunm0lB1Pnl8sZSuWQXc25U0yjPpBNaHYCxnqnNzwduLeI3krCb7Y4uHVeZHoPJgBuUOmX7QWSTI5K6C5d/kchhmzvLJp8gnbHK3Sb/5GHy4qRhMUIQXi7uF4YnrwDkqd/llwYTh9eppSmPxn5+8B+LQkWlprUp3gIspx9ZCDVw5TmLuZok0lHmssgIMWyR1vfg76KuD1dYc8WC7x1Vgrma3jkQ3PiTCE2QfqiQTtWSHR8aPBrFtBXSoask2TjFFCQ36XtBSlKlPJ3qHuphmIVrRxqnN4LP98W/ErJCMOWBfrV/sEC7d51nb72HSqXMKNvaUdmGgIv029C+Ol9rNBZzsqMOz8rREtNOflrNquZxmOTcX445C19jhRtgRu51i4+q0SAarcTrMzr0Xl82ongnwp7MaDF38U24G3BfDsFElZC9iM3EZRnKXNHZTgRhepNgKWpzK12xTFlvvEDzI/BvQcvc1NN6+o1CH3vG86
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5850330a-80c9-4837-3056-08db1ea49a45
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2023 00:40:51.6326
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1q3AyPHN7z3Z4xpkzDi43mlGijwbkYDuJBTMOJrtQOMZf6DVh7kW4fwmqhonDSbvUEGc9K7GcW1F8ATJwGb/Rw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR10MB6748
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-03-06_14,2023-03-06_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 malwarescore=0
 mlxlogscore=999 bulkscore=0 mlxscore=0 adultscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000
 definitions=main-2303070004
X-Proofpoint-GUID: 0JcefRUupeDfw9GvtYrWUTXOm1H2e8gr
X-Proofpoint-ORIG-GUID: 0JcefRUupeDfw9GvtYrWUTXOm1H2e8gr
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/06/23 19:15, Peter Xu wrote:
> On Mon, Mar 06, 2023 at 03:57:30PM -0800, 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.  The
> > system has THP always set, so a huge page is allocated at the first
> > (write) fault when libpthread initializes the stack.
> > 
> > It would seem that this is expected behavior.  If you set THP always,
> > you may get huge pages anywhere.
> > 
> > However, I can't help but think that backing stacks with huge pages by
> > default may not be the right thing to do.  Stacks by their very nature
> > grow in somewhat unpredictable ways over time.  Using a large virtual
> > space so that memory is allocated as needed is the desired behavior.
> > 
> > The only way to address their 'memory bloat' via thread stacks today is
> > by switching THP to madvise.
> > 
> > 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.
> 
> > - Other thoughts?
> > 
> > Perhaps this is just expected behavior of THP always which is unfortunate
> > in this situation.
> 
> I would think it's proper the app explicitly choose what it wants if
> possible, and we do have the interfaces.
> 
> Then, would pthread_attr_getstack() plus MADV_NOHUGEPAGE work, which to be
> applied from the JVM framework level?

Yes, I believe the only way for this to work would be for the JVM  (or
any application) to explicitly allocate space for the stacks themselves.
Then they could do a MADV_NOHUGEPAGE on the sack before calling
pthread_create.

The JVM (or application) would also need to create the guard page within
the stack that libpthread/glibc would normally create.

I'm still checking, but I think the JVM will also need to add some
additional code so that it knows when threads exit so it can unmap the
stacks.  That was also something 'for free' if libpthread/glibc is used
for stack creation.
-- 
Mike Kravetz