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 C883EEB64DA for ; Wed, 5 Jul 2023 09:54:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 343C76B0071; Wed, 5 Jul 2023 05:54:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F4176B0072; Wed, 5 Jul 2023 05:54:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BB578D0001; Wed, 5 Jul 2023 05:54:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 095A16B0071 for ; Wed, 5 Jul 2023 05:54:37 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C5476120AFF for ; Wed, 5 Jul 2023 09:54:36 +0000 (UTC) X-FDA: 80977098552.28.3E22811 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id ED03610000B for ; Wed, 5 Jul 2023 09:54:34 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688550875; a=rsa-sha256; cv=none; b=RA8F87kLdT744+RVFyvpzAaIs4gYo57t8Z1jm/IxDkBibsLdunpSCNOnGbv5bWRZp2DDcU om6DVm3Y7pHdWoGz3KNmj1/u/hK/241XX96lhDDTY6z3KART2Pfdvw9Ifi4K9qZjeycQ4U wjNDTV94zwetH/oEqTWEHmZzo5FNSqU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688550875; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k9/+RLDe9FpmKu26VyNlwoRFGISOlN1AxYquFpBVOTE=; b=dsiSfTNR+0l0fYnpMtpOKtm36SJR+ZzF2a+/O0gaNQ3E++zdISMEBRWryVgxRDuTFLITGN jmUJAhbpHYDCNswvX7/bZXacKIm3dbEFyvRxMBU6vfYLMt4+0gqqD2Yx3ZAt/3zCwIuFY6 nAS1pWOXN0AqgQEPkasG2sxcJmEdpFk= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 39DEB16F3; Wed, 5 Jul 2023 02:55:16 -0700 (PDT) Received: from [10.57.76.116] (unknown [10.57.76.116]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 253F83F762; Wed, 5 Jul 2023 02:54:32 -0700 (PDT) Message-ID: <4ee6e325-30ea-f74c-7d73-10a5d1453d01@arm.com> Date: Wed, 5 Jul 2023 10:54:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance To: Matthew Wilcox Cc: "Yin, Fengwei" , Andrew Morton , "Kirill A. Shutemov" , David Hildenbrand , Yu Zhao , Catalin Marinas , Will Deacon , Anshuman Khandual , Yang Shi , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20230703135330.1865927-1-ryan.roberts@arm.com> <20230703135330.1865927-5-ryan.roberts@arm.com> <6865a59e-9e40-282d-c434-b7c757388b65@intel.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: ED03610000B X-Stat-Signature: 4xoih4yi1dc53fixqh98qjfwbn1t79hz X-Rspam-User: X-HE-Tag: 1688550874-920827 X-HE-Meta: U2FsdGVkX1+jdt6LT12KGCLfqwb2FwWvWHUDSITuV8xQRUYouciky26Yp4ZgoJPc9OobxoshRmpx2naiVkrv4tRN2Is6XEGuCvzmLR+V7PhHUlZBTEEVxlAq9g31LxYfJ1NThFwYwfnaY1Dz3D1VKPUt065kUsnj9xjkRc4CTzwlHQvm+WLvVNYbfiP8KXnq2tebfrGtIrFMcWMmVuWW06cX21N2hKYwswZxi15DQ1gNoaWbrxc1Pg7Sd3GQruqD4Ghubtfs7Dk5dB2tC+cD7EYXcpCdiEoBKSRuYsf9TuXwWdpQkP7SZKVOwswWd7ke4Ep+/f9G5lwxbtpKDyZQINeUTaYa8mcJjI1Gyy512QUd8WH/jmTIzYnkR8gqL8awarqY8/NN4+YnGv3Yi+4/8GAjYEQ7XoYafgfVAnJ07Zy/oV0kA9YTSoptffWdEZuQHoQNMtiX0sU8PDfph+y4o1yGiIt/OMPsHOzWPoHTH7AEcXD9LRfhKXgXJF9I9Du0y55HAvsfCnVOQF9Z+D3/xw/bv/XcPR3lzNwIk0XtVnShN2u48TwPWaD8c7NXrOlVHJ943fLXjO7ikXWYEU3wqPAMAoEKEgwpzWvQc9u1KiRch5000kWipWVdCLO/EbckzjVkmsnfpX1MMKQbmumrVWbkJLY7MPfegByc+qA8TMClxRGpcJyPyRKGcej9bm3q8u9Sc6OIY9In5RFP7m30sfw1X4kyfEqDj25kFWxBvVOSbo6pIY9GzhWENj+zJ1PD8DLBOiSBaQ5gZr8dFWXCnDR/7xcGQjph2e9L5FNAt7HRpLdOHMJvplvZRmYSO4eKJqr7wOEuqkkcwdIv/q3pSnsl7ngJALawfyvZkaHsnvEc8OmXbFD5+W09UQid9FcembaygY4AsjM5uLgxQQVAu3dUayWWafPtRCcjePBObKDscsbZySf/7bU0mvoj/ljNN9tkn44+p6QoXw3loFT AJ5wovGe Y/bNb4GFbVxfSTOyZodXXpTRkpxA66VdOGkh2P555iJ3lHnLBVtRhUnznpw7I1WKuOJjjkJMs5HK+MCYWRgVTk/FqL3gHxplzEE3UMy8IGv3z3ZsjtuQlKqPo6EHcAdhY02oWzU4Ih4aGA4QkSIMHqOPZd9D+0GY9Jy3O 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 05/07/2023 00:57, Matthew Wilcox wrote: > On Tue, Jul 04, 2023 at 03:20:35PM +0100, Ryan Roberts wrote: >> On 04/07/2023 04:45, Yin, Fengwei wrote: >>> >>> On 7/3/2023 9:53 PM, Ryan Roberts wrote: >>>> Introduce FLEXIBLE_THP feature, which allows anonymous memory to be >>> THP is for huge page which is 2M size. We are not huge page here. But >>> I don't have good name either. >> >> Is that really true? On arm64 with 16K pages, huge pages are 32M and with 64K >> base page, they are 512M. So huge pages already have a variable size. And they >> sometimes get PTE-mapped. So can't we just think of this as an extension of the >> THP feature? > > The confusing thing is that we have counters for the number of THP > allocated (and number of THP mapped), and for those we always use > PMD-size folios. OK fair point. I really don't have a strong opinion on the name - I changed it from LARGE_ANON_FOLIO because Yu was suggesting it should be tied to THP. So I'm happy to change it back to LARGE_ANON_FOLIO (or something else) if that's the concensus. But I expect I'll end up in a game of ping-pong. So I'm going to keep this name for now and focus on converging the actual implementation to something that is agreeable. Once we are there, we can argue about the name. > > If we must have a config option, then this is ANON_LARGE_FOLIOS. > > But why do we need a config option? We don't have one for the > page cache, and we're better off for it. Yes, it depends on > CONFIG_TRANSPARENT_HUGEPAGE today, but that's more of an accidental > heritage, and it'd be great to do away with that dependency eventually. > > Hardware support isn't needed. Large folios benefit us from a software > point of view. if we need a chicken bit, we can edit the source code > to not create anon folios larger than order 0. >From my PoV it's about managing risk; there are currently parts of the mm that will interact poorly with large pte-mapped folios (madvise, compaction, ...). We want to incrementally fix that stuff, but until it's all fixed, we can't deploy this as always-on. Further down the line when things are more complete and there is more test coverage, we could remove the Kconfig or default it to enabled.