From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2053.outbound.protection.outlook.com [40.107.22.53]) by sourceware.org (Postfix) with ESMTPS id 49BB4385B535 for ; Tue, 16 May 2023 15:38:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 49BB4385B535 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ltMF6+LZmmIP7zfs24ElGvzls7IPMEegoImGCLGXzGU=; b=DYHmyOKpmYuDUu0C8cDuZ/kqLmaVObr/g1QJ9TNIlAKhXKlXXLtGgITBH7SReaJnPiYgLkq/LRunMTKJw2omlU4/7wZn/IybEluRbNFLlXVkr4f6IH76fqNs5XFQyxjsHmfx5SEIy0XEaxe9eih4zuAqFUaqICUewEhR/nC6Tgk= Received: from AM5PR0502CA0001.eurprd05.prod.outlook.com (2603:10a6:203:91::11) by DB9PR08MB8700.eurprd08.prod.outlook.com (2603:10a6:10:3d0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.30; Tue, 16 May 2023 15:38:26 +0000 Received: from AM7EUR03FT057.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:91:cafe::20) by AM5PR0502CA0001.outlook.office365.com (2603:10a6:203:91::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.33 via Frontend Transport; Tue, 16 May 2023 15:38:26 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT057.mail.protection.outlook.com (100.127.140.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6411.15 via Frontend Transport; Tue, 16 May 2023 15:38:26 +0000 Received: ("Tessian outbound 99a3040377ca:v136"); Tue, 16 May 2023 15:38:26 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e3ff4ac3a9ed2654 X-CR-MTA-TID: 64aa7808 Received: from b859e3e064d6.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8857AE3D-7C0D-41C0-B4D0-6E8F1BBC1853.1; Tue, 16 May 2023 15:38:19 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b859e3e064d6.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 May 2023 15:38:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OuUafXpA0SVSP4TkkP31cOV3TlIn/zcMLsloDSd0vD8gcMpkdaUXItNdkGRXJ/4SxP6yTTwHwE6H6UxRQgVj9mtqlq80WJdnbW/rFI0+luOLVM9hVD/XN2vbvxMGbnleQmq7/JihwoDddRT0sbAChfa+o957wxi0+RKKwfSy6a3s4PV0Yy6fWMb41jY+QVTs1MEnv1+lmuQjcv5Gp6oEKx+n7a5lbW6sHub4nnP0cvZ8skYtXzabtVZAy84+KWBqRYlXH1hQILVCIb8K63tpK8dB7aa83lSaAVmJDCR+yYkvFGUIWJZls+sNe1cVz/JgThyn8k+Hq3rRugZNcV2iVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ltMF6+LZmmIP7zfs24ElGvzls7IPMEegoImGCLGXzGU=; b=jjVVcoBS9yOZV5AQgxXkMWu4iYU7o2PJc8Q/d7hfk7T9PlRNilxq3jp/ZONgvy9QTB7MkijD+6xfsJBLdnQ1a0PIWMzXzxo76PNhqV2FXyZ+M9qQ5PVXJpZnJuH/4vcEmQu07DH5KAiZxOS7PCChKa3VN6QbRMf1ayo7dBrVCWi+OCTKEtO2yDrB+yi8xexr9jrVSvZr+uDTQ/sXmqylYBhM82+skoKDUli1SYH0lMyQ/UuFRN2+zNlUsM6IFKq6ZLDnK6CI8sEQPkmULVEnWYpdysOwvnrM7J5s2QXlrV47zXOJ/1ByjuwHyPRM9Fp/E7xCfYh8m9VGyu8XosjdlQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ltMF6+LZmmIP7zfs24ElGvzls7IPMEegoImGCLGXzGU=; b=DYHmyOKpmYuDUu0C8cDuZ/kqLmaVObr/g1QJ9TNIlAKhXKlXXLtGgITBH7SReaJnPiYgLkq/LRunMTKJw2omlU4/7wZn/IybEluRbNFLlXVkr4f6IH76fqNs5XFQyxjsHmfx5SEIy0XEaxe9eih4zuAqFUaqICUewEhR/nC6Tgk= Received: from PAWPR08MB8982.eurprd08.prod.outlook.com (2603:10a6:102:33f::20) by AS2PR08MB8383.eurprd08.prod.outlook.com (2603:10a6:20b:55a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.33; Tue, 16 May 2023 15:38:15 +0000 Received: from PAWPR08MB8982.eurprd08.prod.outlook.com ([fe80::13be:967d:6e80:432f]) by PAWPR08MB8982.eurprd08.prod.outlook.com ([fe80::13be:967d:6e80:432f%5]) with mapi id 15.20.6387.030; Tue, 16 May 2023 15:38:15 +0000 From: Wilco Dijkstra To: Adhemerval Zanella Netto , "libc-alpha@sourceware.org" , Cupertino Miranda Subject: Re: [PATCH] nptl: Disable THP on thread stack if it incurs in large RSS usage Thread-Topic: [PATCH] nptl: Disable THP on thread stack if it incurs in large RSS usage Thread-Index: AQHZc60G15loQEfRP0Ssp6oo6IG39K9IhkbigBM/uICAAWQLPg== Date: Tue, 16 May 2023 15:38:15 +0000 Message-ID: References: <20230420172436.2013698-1-adhemerval.zanella@linaro.org> <4115d7fd-d7a7-cdb1-3833-daf45186480f@linaro.org> In-Reply-To: <4115d7fd-d7a7-cdb1-3833-daf45186480f@linaro.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PAWPR08MB8982:EE_|AS2PR08MB8383:EE_|AM7EUR03FT057:EE_|DB9PR08MB8700:EE_ X-MS-Office365-Filtering-Correlation-Id: 8fbe429e-e5ec-4cab-f63e-08db56239743 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: h+n6l208QtpQQfYsU3ywj5PrDnFyJRPHGhYEW9axXtiKCTheyoe/zgwA6PxlMwK7a+UOt9RptEIEAKCn6gZEVdGeQ/ECBJSBzo6KdAQd/9KTxk30hierpYdZzD/ygsr0675cOvpB4nQVHIw0KxikQjiIlq+MtMJrIEs8+JJlVqaNgEW9iJSKrzLDFh/BSisG+09+a/dDCKMuybyhA3RWvHdCZ9EUDAHY7+fbd8BXm8Lw6ykOIHdoUJBjaCeF8WJbUU0RFcP8LiSYV9ecU7a34ntzNR33aZic7R+PQDfWFGbv2CZIS+LS9mR+4gnVu9wPpKxF1cXuJJBa7fbK4lvBFCHE1Vcu/kYl62g+hULPEDR3MqoAU8X7Gqz9H2HCCN7SDSIcZuIhTzHHPndRE9PkpyHoakOIRbUZkMUpVLhv8mPz0L6dOqUilLTHd2vAoI6ydEUAySQo3NKfesUagvMoamNcjTmO0Te9e1am4MKGSsmKKcn/QuY9I0CfTMUQAbQ3u/GCYBdSKwlJqfTYLnRZQH8JIyaZgGnZUVzOg1JUjK5PKJoKjLJpmNfTXlC87mHzi8OJbpLL+hLcBxBQ+hcaQOBI5gzWq6qiKk5Qga2RgGwAXmEhOcPEx3SPcNIkNeTo X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAWPR08MB8982.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(366004)(136003)(376002)(346002)(39860400002)(396003)(451199021)(76116006)(66556008)(66446008)(66476007)(478600001)(66946007)(64756008)(91956017)(316002)(110136005)(7696005)(33656002)(38070700005)(86362001)(26005)(83380400001)(6506007)(186003)(9686003)(41300700001)(8676002)(52536014)(2906002)(5660300002)(8936002)(71200400001)(55016003)(122000001)(38100700002);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8383 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: cc0b61df-3e6e-40f1-aec6-08db56239097 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hp2iyENjo/Uufx+vHFOF1oTbuuVczQBthZILr6yVzBnMd1UByI9YP1HtKga5Phbo6R+jS0Uxxi3mNUtpivLC0Ak4wIjUBNVmJbdDvlRu92GmehC+jLBLuLXpBU1+fpJU2EnhHZCJOB865GZcbzFRkCLBoavZJXZfqHKPb+o/r4BvR1nUQ19do1gGW6SImuab3snm59IYiCIqjkNe1bKc9UmM8qpDugLwzMp833XkoUGlTmWvJv+JwJUGjBlXW4drsUumViVpA/3VYE1ai6M+FdgfuupiALwh7+3FtyXRlV0QQBMMxw438zKLMvfqQO05f55W/8OaR51NYidXUm0IwCwHXoV9T2qcfxrXVAAtEqAPXUzCuiQH13AJR5bmrhpLBBidXVUKG175gllN0orLfORxQCu4lZBOALSGfoL7HLTLCr+6va+GhsE34Chmu8jK/JcPJ6kgBqSMroZy16qgplh9A2+qilT0ra3PHfg4RvON6ygSop4eYG+3iUQTnSdHg7EIiD2GZHDbnRtclOwSfxW681iXVWoq2qRfO7RRFvqL4r9EUu3hAD5Saw6SB8ck/VSMfDHqoeuqWor5e+zlCqSYjhBkmRHkkjKtMPQ2R6q1gwUKPUVW1ngtmn3gWoOrlB5IH06KTdfG4+e90lukyluLvBWHyJiz3rDS8nGjiw9szVUYqVfbL1B3DixgjPUCZm5LmIrjpVDlqjlTbnFkDRuo/q2+Ih2QT+wfIXDYk51H0ZEFk3k0gzCYHfbD4dv2 X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230028)(4636009)(376002)(346002)(396003)(136003)(39860400002)(451199021)(36840700001)(40470700004)(46966006)(40460700003)(70586007)(70206006)(478600001)(7696005)(86362001)(110136005)(316002)(33656002)(47076005)(26005)(186003)(9686003)(36860700001)(6506007)(336012)(83380400001)(52536014)(8936002)(5660300002)(8676002)(2906002)(55016003)(81166007)(40480700001)(82740400003)(82310400005)(356005)(41300700001);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2023 15:38:26.4089 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8fbe429e-e5ec-4cab-f63e-08db56239743 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB8700 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Adhemerval,=0A= =0A= >> This still doesn't make sense since if _STACK_GROWS_DOWN, mem =3D=3D gua= rd, so=0A= >> this will always execute the madvise. =0A= =0A= And if !_STACK_GROWS_DOWN, we never execute the madvise. So I don't believe= =0A= this is correct, even if it behaves like a nop in some cases.=0A= =0A= > Yes, if THP is set to always this is exactly the idea of this patch since= =0A= > afaiu the kernel might still back up the stack with large pages if the = =0A= > request a size is smaller than the default THP.=A0=0A= =0A= If a mmap start/end range does not align to a huge page, you get small page= s=0A= at the ends because a huge page does not fit.=0A= =0A= > It is only an issue if=0A= > the guard page address is not aligned to THP default size, which will=0A= > potentially trigger issues Cupertino has brought (since we do not prior= =0A= > hand which is the mapping flags used on page used to fulfill the allocati= on). =0A= =0A= I don't see the claimed issue happen. What happens is that if you request= =0A= huge pages, you get them. And that is what increases the RSS size.=0A= =0A= >> As I mentioned, I couldn't find evidence that=0A= >> the claimed scenario of a huge page allocated, written to and then split= due to the=0A= >> mprotect exists.=0A= >=0A= > I adapted Cupertino original test to allow specify both the thread stack= =0A= >and guard size by command line.=A0 Just:=0A= =0A= The RSS size difference is not evidence of an issue - you asked for huge pa= ges=0A= and you got them! I verified they are definitely huge pages by counting the= TLB=0A= misses when accessing the stack.=0A= =0A= >> So the real issue is that the current stack allocation code randomly (ba= sed on=0A= >> alignment from previous mmap calls) uses huge pages even for small stack= s.=0A= >=0A= > Keep in mind this heuristic is only enabled if THP is set to 'always', me= aning=0A= > the kernel will try to back *all* the stack with large pages.=A0 The issu= e is=0A= > when the *guard* page is within a large page.=0A= =0A= Why would that be an issue? In that case you can't get a large page.=0A= =0A= The question is, under what circumstances are huge pages in stacks benefici= al and=0A= in which cases are they not? If have a good answer to that, then we can aut= omatically=0A= do the right thing without needing a tuning.=0A= =0A= Cheers,=0A= Wilco=