From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23846C61DA4 for ; Sun, 12 Mar 2023 00:56:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D33C6B0071; Sat, 11 Mar 2023 19:56:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 283906B0074; Sat, 11 Mar 2023 19:56:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 171EB6B0075; Sat, 11 Mar 2023 19:56:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0495B6B0071 for ; Sat, 11 Mar 2023 19:56:12 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7623A1A054E for ; Sun, 12 Mar 2023 00:56:11 +0000 (UTC) X-FDA: 80558429742.29.5878950 Received: from mail3-165.sinamail.sina.com.cn (mail3-165.sinamail.sina.com.cn [202.108.3.165]) by imf05.hostedemail.com (Postfix) with ESMTP id AC138100005 for ; Sun, 12 Mar 2023 00:56:06 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.165 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678582569; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Qt+OxrNpuu0rB8PzEVQfSDGncfzU0PPh8dBlaQCYiO8=; b=H6peEFxJxrbinX1qez27cyujKpKlkh9Ab0x61RioMgzzIdJ3U8BbBodm+lumPVlRN9fg63 Hmx+5vPlmdrIeDwCtS3fwjMnguY4ElHFcvMMjA3EZ1kL8WsQgf/FOp+PLmHryCUKZADxpR 6lBc5Ir3ac5Wqpctu73EMqkHBPJpqdo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.165 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678582569; a=rsa-sha256; cv=none; b=ePGfOz/kUAAh9J47h3gt5pZWuU3indFyd9P2qhD1y1F2/sKsg8F9yGN3/uhApaV3NyyClB 0mkXuHXwZUhkWJpfCB1U/DdxZ+AoHL4JOtYmh9F116GfLenG5LTwbsv/iSjO6ilDD7abHh dH8De42woTWFahlAluacOuNXZWKxfk8= Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.32) with ESMTP id 640D23040003333F; Sun, 12 Mar 2023 08:55:33 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 838479628951 From: Hillf Danton To: William Kucharski Cc: David Hildenbrand , Zach O'Keefe , Mike Kravetz , Peter Xu , Rik van Riel , Mike Rapoport , Linux-MM , LKML Subject: Re: THP backed thread stacks Date: Sun, 12 Mar 2023 08:55:49 +0800 Message-Id: <20230312005549.2609-1-hdanton@sina.com> In-Reply-To: References: <20230306235730.GA31451@monkey> <20230307004049.GC4956@monkey> <20230308190206.GA4005@monkey> <20230309233340.GC3700@monkey> <9F855331-33B2-4366-9375-988B0D3DAC98@oracle.com> <9f44de08-b484-baa7-80c8-0a02a7abb717@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AC138100005 X-Stat-Signature: isbkzhy3afpa8jmwdi3yw3s4n7ypqcy3 X-HE-Tag: 1678582566-490899 X-HE-Meta: U2FsdGVkX18lhkwOGhR7pPALB1bQ9AxButOzRuS4Gi8Nr9XUoXp1gLdFqtqTGInh71xqI6hZ6OsGj6pMgyJNpOCjX+gdghmg2Xuggk/VbsvK5eafezNAMxG/r9xNe8M/MYQvZIm5K24j3dHmrC0F7hgVqhK0iBVhEiXcc6Jlhm9Jtcb2n+9VKenaNggtrM3csG3dXmHBZJNAh+qPUXekycLnY+0j92D6i1QATcW0uJBLZrA3qZiYs+q5mqJCphtGEYwvAhMPTLDctKf8w3GZEvFyPpN62gkHAjSk2RA4CyLjWgCgW6C2EO7wR0UDYq3BReTaWIkFhCscndHA5PPw3eBZDE/c5N9UnDCRQUGegTJ/E0m1kXRhY1+8T9Pk8DxfrUOFvxYuxElFMwkHLIGqUKXYI/5twyM/09plQatWUHlN3PGFogBSrOMBwnBLkKfwBg4yCr+aVJ93/XnU06o3cqU6G83lKUTOSzbuvgF0ORIkd/b6bl8KK89mehbvX9zcxJqIIoPSbnZh9225SCBwoFsStjOTEAvFZ5RYWBxAs/xwzMxz3z/iK2dZkQby2rFX63Vv2sBWogyxPbLb1+hq6gjf5TMzcH7DTcKJ7RQWrQIBZru+dpp2lwEwYfIrM/SLQT6+ZXcfBR2+NVc9g/AFdPjfViMIVEYeyQlo/URaV3KsaLgmWaRi2kCgbLGqCiiPuEmFRTxSOIp8pmt0sF11h8/DqqvwDK0Pg/xULf90wFWqinmCNop4ehUI/53I0KkxOFQSuJ4DRJns53PFbwOW+RvDFnWyYkQXiXPP5WrhGUcERmUODIEppoOBweSs7aT0tjbA+nVA4RjQ2OXFIsUFS6m6olvG6LEOyYEF+Bs9uR+141Y65YlETU95fyw+Vs9HZkgsv/7PZMWYcTme2u4JhpCb6bX+QqLQpEW1UFreHjIeBSIhOhOp5LrvAI9UAWmpsgubBlB+vk14d4WJ6oF KqMM+HW4 NFTfrIme+88OMBIK/B3akKtRZcgwu9favAMMQy9h4KCb9yJEmPF3OYID9DqkyD/4CipwUtyM2eiMUlkXnTQa8dwh1z4D2Cpwaom0S4b7/UNK5LaAsCTEfN/8Uee9JZ9LjUuKXWWW/bdgQSH/BCpNKq8uYYs9HYWMImJM4 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11 Mar 2023 12:24:58 +0000 William Kucharski >> On Mar 10, 2023, at 04:25, David Hildenbrand wrote: >> On 10.03.23 02:40, William Kucharski wrote: >>>> On Mar 9, 2023, at 17:05, Zach O'Keefe wrote: >>>>=20 >>>>> I think the hugepage alignment in their environment was somewhat luck. >>>>> One suggestion made was to change stack size to avoid alignment and >>>>> hugepage usage. That 'works' but seems kind of hackish. >>>>=20 >>>> That was my first thought, if the alignment was purely due to luck, >>>> and not somebody manually specifying it. Agreed it's kind of hackish >>>> if anyone can get bit by this by sheer luck. >>> I don't agree it's "hackish" at all, but I go more into that below. >>>>=20 >>>>> Also, David H pointed out the somewhat recent commit to align sufficie= >ntly >>>>> large mappings to THP boundaries. This is going to make all stacks hu= >ge >>>>> page aligned. >>>>=20 >>>> I think that change was reverted by Linus in commit 0ba09b173387 >>>> ("Revert "mm: align larger anonymous mappings on THP boundaries""), >>>> until it's perf regressions were better understood -- and I haven't >>>> seen a revamp of it. >>> It's too bad it was reverted, though I understand the concerns regarding= > it. >>> From my point of view, if an address is properly aligned and a caller is >>> asking for 2M+ to be mapped, it's going to be advantageous from a purely >>> system-focused point of view to do that mapping with a THP.=20 >>=20 >> Just noting that, if user space requests multiple smaller mappings, and t= >he kernel decides to all place them in the same PMD, all VMAs might get mer= >ged and you end up with a properly aligned VMA where khugepaged would happi= >ly place a THP. >>=20 >> That case is, of course, different to the "user space asks for 2M+" mappi= >ng case, but from khugepaged perspective they might look alike -- and it mi= >ght be unclear if a THP is valuable or not (IOW maybe that THP could be bet= >ter used somewhere else). > >That's a really, really good point. > >My general philosophy on the subject (if the address is aligned and the cal= >ler is asking for a THP-sized allocation, why not map it with a THP if you = >can) kind of falls apart when it's the system noticing it can coalesce a bu= >nch of smaller allocations into one THP via khugepaged. > >Arguably it's the difference between the caller knowing it's asking for som= >ething THP-sized on its behalf and the system deciding to remap a bunch of = >disparate mappings using a THP because _it_ can. > >If we were to say allow a caller's request for a THP-sized allocation/mappi= >ng take priority over those from khugepaged, it would not only be a major v= >ector for abuse, it would also lead to completely indeterminate behavior ("= >When I start my browser after a reboot I get a bunch of THPs, but after the= > system's been up for a few weeks, I don't, how come?") Given transparent_hugepage_flags, how would it be abused? And indetermined? > >I don't have a good answer here. > > -- Bill=