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 E152FEB64DA for ; Thu, 29 Jun 2023 01:39:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44B0D8D0003; Wed, 28 Jun 2023 21:39:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D4BD8D0001; Wed, 28 Jun 2023 21:39:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 275678D0003; Wed, 28 Jun 2023 21:39:14 -0400 (EDT) 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 1665F8D0001 for ; Wed, 28 Jun 2023 21:39:14 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E0A2BC0B32 for ; Thu, 29 Jun 2023 01:39:13 +0000 (UTC) X-FDA: 80954077386.01.03FF884 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf27.hostedemail.com (Postfix) with ESMTP id 1DA3940007 for ; Thu, 29 Jun 2023 01:39:11 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=W6LAHQ9M; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688002752; 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:dkim-signature; bh=ux9B0srClyCZWsFVsMJo+q/yRz7KZe7H2zTVS/BvmEY=; b=wuNhjPBfkBTxlv42DiEY9rA+PsJkqYtO/khK6D2WUX6qnJeKZr84Yf/e838aT0U/QpUJ7V 59Fwqox9PCDbYemsekCSN+OMut8ji3c2xMbZf5UGs5rFipg+NxesI9bPF84ft7h3jstSHa UvvFyWC8J6KfRubeHrwsJVmasBlOyEA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=W6LAHQ9M; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688002752; a=rsa-sha256; cv=none; b=jW6tjCk4xssdNPNVbcC8ghQeVyq8F4FZJ84iiEsS5NwiCqrVMaCxIfkHNNnvpJSbS+2o47 O3H1MX8LTL8SSjy0j0zU0z8a1+lbv4N48H2gcEBkRlQG1um6woorFB7pTJHlUfcGotczq8 6MNIk57f0xXIuUYbA45KMTzSaqHX53A= Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-553b2979fceso67803a12.3 for ; Wed, 28 Jun 2023 18:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688002751; x=1690594751; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ux9B0srClyCZWsFVsMJo+q/yRz7KZe7H2zTVS/BvmEY=; b=W6LAHQ9MU7AqXT0poOsZHvm7H0Hux1rT4jeGdWOdyyIy9x4KvcSwcpESQvub372rha PcS2S7s9EGLVRenNs40RPeNR1lHzNmhgCXNs2CnUL1/ve7YQqx/5URo9gmaKbjtD2Zd4 NFG8SOwMO1U6FmYcg+G1SoUy5Iy9A6eYjnlGNUoRsSxQnVPkgo9EJO1OO97MhvnuGiaB T+vwP99cg5QDycEK2YsDZplyh8K1htp31VQFkb99p16T27/RjXB1LGTXJRdC0/jM38yp CK6HHxcyHt8RGgCC34+SjP64QMWV1A1ky3yF20JPIyzGobP1vSSv7koi6Y6N99mQcFsR YXGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688002751; x=1690594751; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ux9B0srClyCZWsFVsMJo+q/yRz7KZe7H2zTVS/BvmEY=; b=CIZOzy8dbkyLNQSU2jahLRoQ5YuhnP7MH/bYjYgLSODIdEpIXK7Z2geXlEDsHUbIPr fq9qMiSP5n0kE4LCOx3gnkT1vregHuKt0O0DfqnYuOL6caghYfFANB4emEnRMsERVzre RwHfXqJ6euDYUfzAaTNAXEiHO2HKp1jYn/m3aQ74O5euG1jRWYgot86x8IGiytj6R2fZ BF/ex6xPnZ+FVO/ltUxdZk1E5D8tDChhiFJNF6+wm3UIL1QcQT/v/XGx8PIan52MWHA0 51khKiYcUNeXFQhh59mkI9ZQItSGpyXEbHyZBKRTTeeKBaUBbFdnoKwga9k3yO/ERU6J vysQ== X-Gm-Message-State: AC+VfDzdS3sqlX1z0Y+YIof3gr4vPohIFGgVPV4rr+hIpwdVc++KBLpe NDzgQFKY2Z45UiKqV578CfQ6v/BriYRSqk0bnss= X-Google-Smtp-Source: ACHHUZ7XV721JF+3Hut1ZfFxeuXwoMOKYJDzX2eAcfRiSgLDFWN6VL4HSkG/y2opKdMIB8ABEkCpkFIucyPLdGZCgYU= X-Received: by 2002:a17:90a:35c:b0:263:6cb:5b95 with SMTP id 28-20020a17090a035c00b0026306cb5b95mr6402422pjf.14.1688002750857; Wed, 28 Jun 2023 18:39:10 -0700 (PDT) MIME-Version: 1.0 References: <20230626171430.3167004-1-ryan.roberts@arm.com> <20230626171430.3167004-9-ryan.roberts@arm.com> In-Reply-To: <20230626171430.3167004-9-ryan.roberts@arm.com> From: Yang Shi Date: Wed, 28 Jun 2023 18:38:59 -0700 Message-ID: Subject: Re: [PATCH v1 08/10] mm: Kconfig hooks to determine max anon folio allocation order To: Ryan Roberts Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , "Kirill A. Shutemov" , Yin Fengwei , David Hildenbrand , Yu Zhao , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Christian Borntraeger , Sven Schnelle , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-s390@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1DA3940007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: r58eciobmubcpanpek3ngpe5fchium8o X-HE-Tag: 1688002751-359514 X-HE-Meta: U2FsdGVkX1+mST2TeaDKjRhrB/k6gKGwCFdwg8AHtDixGKnwe1eIgM19dvu+mC9R/40cZajx28f9wA6zIrWo11kYP+PPJtHeQmdttSUotcmeSxyEeTPpmvw8CpWNetXeBU2zbCOvyvqTvb93OxnUiya2ADTHkNb5/PU0R1I1JlFxZ2ANGfCLGMgP9m4ME8f1nwOBlDTA80R3o5uoMbqDF1eKIAM4JFOiaYHDTdXu/aasdgbEBBaGosoP6Fm5j6YGHXXDVnuKKDMlQZyjbWrdc6JGvOq9KLPXSfAYai5UGuVmCaR7uAI79Apni3YteE/LLp6taWuRCUe3irRclKD5CBqyfXG2OvaHuBuosIIKxF+GwGHtWUIDll7Vbu8/F+iRS3Ywac357NBnEtgeLbhrXiDqR/yZ3S92fJIEqarTZrzxNY61TnRldoEtinoigVX7/oNf4koV5NwTmP3hWZERlXIBqG2xQ9EI/9Rr5VIfsBM4naicj33v6rVNNnmBe+261yArhUBFBI4KEch0vy/ZffgvZ7g4Y7dlZpTTFq5DDDj5LZieTTp0gnB20cnshPNCByJwC1vrCduBJ4UqiDC6NvJVLno2XBXEpaqvdaZrStu/z3IxH8gkOsIsrao13cCsQlggQgY6Etw/hvFjnUk1Y0YE0CydhX0uKvG+/WuwwTzsnUnmOp67S+4QcGKdvWTXGUshXYmuKuCDC/Ez4u/MnxZsufGUgFep4pWgxoZUiNvg9IQFU0hP1WeML1hjcqhG3ELdxSIOfgBOhT7A/KPDFN95tI92Djuj+WIbgZwMTqEVput3XunGLv76dNs9T+wFr1IxFeSoRhUxEbLjPEITY8VKkkQ6YYqxVAxHb14w+a6lu7LbMhk5dRG+36tJL6TfFpV+LGg0LeosrwWLU2eaYeeSWTdgkNjpsAiUO4vWrPNniJeihlI2BdfDhgjif8OhWNivCd4vB449XnYUd+0 O4jAsk5r 1QSz9z4CXUcuga+FIYP7WjQRqaGq3SX41Rveeng3zCjeqglRtnTqj6ZBq/lJcl8g6atw83W8bT1JUVfv4/u9dqihOkn/x3ElDIC4INyYdOJ8/tWafAfgI9uFO2l7cYxedzQmHPS6lPkISBr+WKKfDkZjyznV0NUgNOB5A1YcrAwmYQJwPbTUcgIRXl7lMmsbuO/+YHu5s7X3lRWWWL007zIACmrtf2k7yS2WYlW42GARSh5UOZ81dFbSrWFpr5H2O04G5YfXaVfCgFOthVRP/mtATEg1L8DxsjCDlQkTWGLwHp46igzfVk/THMeTFFc/0bq4ERX2bcZ2W8fW+P0At2AKV+w0m3NFCqybHI9PyY9RCw1Sg+QOeF34y9hXXzo/y/xo8puw/hhGM/oTE1iSN85Nu1s2UDD54kz66 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 Mon, Jun 26, 2023 at 10:15=E2=80=AFAM Ryan Roberts wrote: > > For variable-order anonymous folios, we need to determine the order that > we will allocate. From a SW perspective, the higher the order we > allocate, the less overhead we will have; fewer faults, fewer folios in > lists, etc. But of course there will also be more memory wastage as the > order increases. > > From a HW perspective, there are memory block sizes that can be > beneficial to reducing TLB pressure. arm64, for example, has the ability > to map "contpte" sized chunks (64K for a 4K base page, 2M for 16K and > 64K base pages) such that one of these chunks only uses a single TLB > entry. > > So we let the architecture specify the order of the maximally beneficial > mapping unit when PTE-mapped. Furthermore, because in some cases, this > order may be quite big (and therefore potentially wasteful of memory), > allow the arch to specify 2 values; One is the max order for a mapping > that _would not_ use THP if all size and alignment constraints were met, > and the other is the max order for a mapping that _would_ use THP if all > those constraints were met. > > Implement this with Kconfig by introducing some new options to allow the > architecture to declare that it supports large anonymous folios along > with these 2 preferred max order values. Then introduce a user-facing > option, LARGE_ANON_FOLIO, which defaults to disabled and can only be > enabled if the architecture has declared its support. When disabled, it > forces the max order values, LARGE_ANON_FOLIO_NOTHP_ORDER_MAX and > LARGE_ANON_FOLIO_THP_ORDER_MAX to 0, meaning only a single page is ever > allocated. > > Signed-off-by: Ryan Roberts > --- > mm/Kconfig | 39 +++++++++++++++++++++++++++++++++++++++ > mm/memory.c | 8 ++++++++ > 2 files changed, 47 insertions(+) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 7672a22647b4..f4ba48c37b75 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1208,4 +1208,43 @@ config PER_VMA_LOCK > > source "mm/damon/Kconfig" > > +config ARCH_SUPPORTS_LARGE_ANON_FOLIO > + def_bool n > + help > + An arch should select this symbol if wants to allow LARGE_ANON_= FOLIO > + to be enabled. It must also set the following integer values: > + - ARCH_LARGE_ANON_FOLIO_NOTHP_ORDER_MAX > + - ARCH_LARGE_ANON_FOLIO_THP_ORDER_MAX > + > +config ARCH_LARGE_ANON_FOLIO_NOTHP_ORDER_MAX > + int > + help > + The maximum size of folio to allocate for an anonymous VMA PTE-= mapping > + that does not have the MADV_HUGEPAGE hint set. > + > +config ARCH_LARGE_ANON_FOLIO_THP_ORDER_MAX > + int > + help > + The maximum size of folio to allocate for an anonymous VMA PTE-= mapping > + that has the MADV_HUGEPAGE hint set. > + > +config LARGE_ANON_FOLIO > + bool "Allocate large folios for anonymous memory" > + depends on ARCH_SUPPORTS_LARGE_ANON_FOLIO > + default n > + help > + Use large (bigger than order-0) folios to back anonymous memory= where > + possible. This reduces the number of page faults, as well as ot= her > + per-page overheads to improve performance for many workloads. > + > +config LARGE_ANON_FOLIO_NOTHP_ORDER_MAX > + int > + default 0 if !LARGE_ANON_FOLIO > + default ARCH_LARGE_ANON_FOLIO_NOTHP_ORDER_MAX > + > +config LARGE_ANON_FOLIO_THP_ORDER_MAX > + int > + default 0 if !LARGE_ANON_FOLIO > + default ARCH_LARGE_ANON_FOLIO_THP_ORDER_MAX > + IMHO I don't think we need all of the new kconfigs. Ideally the large anon folios could be supported by all arches, although some of them may not benefit from larger TLB entries due to lack of hardware support.t For now with a minimum implementation, I think you could define a macro or a function that returns the hardware preferred order. > endmenu > diff --git a/mm/memory.c b/mm/memory.c > index 9165ed1b9fc2..a8f7e2b28d7a 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3153,6 +3153,14 @@ static struct folio *try_vma_alloc_movable_folio(s= truct vm_area_struct *vma, > return vma_alloc_movable_folio(vma, vaddr, 0, zeroed); > } > > +static inline int max_anon_folio_order(struct vm_area_struct *vma) > +{ > + if (hugepage_vma_check(vma, vma->vm_flags, false, true, true)) > + return CONFIG_LARGE_ANON_FOLIO_THP_ORDER_MAX; > + else > + return CONFIG_LARGE_ANON_FOLIO_NOTHP_ORDER_MAX; > +} > + > /* > * Handle write page faults for pages that can be reused in the current = vma > * > -- > 2.25.1 > >