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 4E998C433EF for ; Fri, 25 Mar 2022 13:33:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C3206B0071; Fri, 25 Mar 2022 09:33:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 772F36B0073; Fri, 25 Mar 2022 09:33:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6398B6B0074; Fri, 25 Mar 2022 09:33:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 559556B0071 for ; Fri, 25 Mar 2022 09:33:06 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 19FA0251E8 for ; Fri, 25 Mar 2022 13:33:06 +0000 (UTC) X-FDA: 79282999572.08.72FBF78 Received: from mail2.intersystems.com (mail2.intersystems.com [38.105.105.84]) by imf02.hostedemail.com (Postfix) with SMTP id BED1F8003E for ; Fri, 25 Mar 2022 13:33:04 +0000 (UTC) X-InterSystems: Sent from InterSystems X-InterSystems: Sent from InterSystems X-InterSystems: Sent from InterSystems X-InterSystems: Sent from InterSystems From: Ray Fucillo To: Mike Kravetz CC: Ray Fucillo , "linux-kernel@vger.kernel.org" , linux-mm Subject: Re: scalability regressions related to hugetlb_fault() changes Thread-Topic: scalability regressions related to hugetlb_fault() changes Thread-Index: AQHYP7uAlCiDRvHUGUacjbJUOtVkhKzPVz2AgAANE4CAABZqAIAATaiAgACU6YA= Date: Fri, 25 Mar 2022 13:33:03 +0000 Message-ID: References: <43faf292-245b-5db5-cce9-369d8fb6bd21@infradead.org> <8E9438A4-56BF-4DBF-9424-2161A488352B@intersystems.com> <1883d31a-639e-8717-39b1-426628cb0d56@oracle.com> In-Reply-To: <1883d31a-639e-8717-39b1-426628cb0d56@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.254.204] x-c2processedorg: 5d7e5ca7-6395-445f-80da-8568a4fc58e5 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Stat-Signature: rjtbk9kizwc9eufmi7uxr9x1by47r891 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BED1F8003E Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of Ray.Fucillo@intersystems.com designates 38.105.105.84 as permitted sender) smtp.mailfrom=Ray.Fucillo@intersystems.com; dmarc=pass (policy=none) header.from=intersystems.com X-Rspam-User: X-HE-Tag: 1648215184-693505 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 Mar 25, 2022, at 12:40 AM, Mike Kravetz wrot= e: >=20 > I will continue to look at this. A quick check of the fork code shows th= e > semaphore held in read mode for the duration of the page table copy. Thank you for looking into it. =20 As a side note about fork() for context, and not to distract from the=20 regression at hand... There's some history here where we ran into problems= =20 circa 2005 where fork time went linear with the size of shared memory, and= =20 that was resolved by letting the pages fault in the child. This was when hugetlb was pretty new (and not used by us) and I see now that the fix explicitly excluded hugetlb. Anyway, we now mostly use vfork(), only fork(= ) in some special cases, and improving just fork wouldn't fix the scalability regression for us. But, it does sound like fork() time might be getting=20 large again now that everyone is using very large shared segments with=20 hugetlb, but generally haven't switched to 1GB pages. That old thread is:= =20 https://lkml.org/lkml/2005/8/24/190