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 43F52EB64D7 for ; Tue, 27 Jun 2023 02:47:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72E078D0002; Mon, 26 Jun 2023 22:47:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B6838D0001; Mon, 26 Jun 2023 22:47:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 530EB8D0002; Mon, 26 Jun 2023 22:47:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3E0428D0001 for ; Mon, 26 Jun 2023 22:47:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 049831408B6 for ; Tue, 27 Jun 2023 02:47:55 +0000 (UTC) X-FDA: 80946992952.16.D0788E5 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 421041C0009 for ; Tue, 27 Jun 2023 02:47:54 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=4Hxtqyz9; spf=pass (imf18.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687834074; 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=lOHMGk1IHW9nIXyoyhy6ScxjHGO05nJh9iYXmQJ8lRg=; b=iIw2tkylUlvFsrDHy5ui9BtxayftBJUZLca722NqsmP7tbyS0VG8e47T5w8BEvdRYwhHjG k/lJ60U3rxp22MqGiESbz3XGnl8ombg4WSPuJ/L9O4JctUFvwyQ+DerCVshJYgKjU9+Pda GryX+WMup/kvSL4WQRIuC648GCaD4gU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687834074; a=rsa-sha256; cv=none; b=R5n4DD0cpJBJz0TU7U555gjlZ7eOEjBy0QNw88/ik+YXQrYlMGirjssP5RWayk4/CFuzlk edzy7UkkhrwYckFNlOLILnoUk7XGXTpxvzDc0/VxTUMbvV86m/wPJcOrbG8abFo54abmmT icrZyLdmMDfRVKrvI7aLNp3w/JKyv6Q= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=4Hxtqyz9; spf=pass (imf18.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-40079620a83so134481cf.0 for ; Mon, 26 Jun 2023 19:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687834073; x=1690426073; 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=lOHMGk1IHW9nIXyoyhy6ScxjHGO05nJh9iYXmQJ8lRg=; b=4Hxtqyz9AC5uq4MuNdUiUTytvXCSHBztZ8M76g0ceKIjnz0PJbRxq4j9xf48iqBl8z uOAa0SjGLlNiOmuesNGIjV6ZEtAaql+t7LaLclTsqLdjWGgtUyTYHYxqyoUKW5PZ8+oA CPN8+kFMBzGza8w1PEdpNYj3T/H/D2g1+h2yVb1dOKdEkXl3MW7xWHGuBNIsJuI2dpbL u9j8wwh7+YY8qKVkw+4OZp6+QPdQwuDjHdLCq2f4ovoXXEUt0D33oYlhzfMu86LnMiFd H0aY0bwtPf9reOaOak+4TqM+JB8fShj+0qc6i2vJ8aAkdg1fOGJQnnkCnCjBag5lncQf /4HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687834073; x=1690426073; 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=lOHMGk1IHW9nIXyoyhy6ScxjHGO05nJh9iYXmQJ8lRg=; b=NySl/XMlnOzmuwyzJm3LMexXvxPxAOVGzdhsKK+jZTauIXXgXpwREYqQgjkqKt+AnG JqbYdWJbdw5gQR0I9msTdUtd7RAwxWmAUTb28C+vBTzG1b1/EVZ3Z3VkZhGht2SfOK4O 1a1rVhD3p1JgB8bZGGx2+mHjtJE3rJlXea6TmObMgBvTVVlyXxpIDt0WaE6sjDLBzGe5 LCvyvx5Tdna560RGGJuN35yeGlu8f85eD3wkeHVd/qR0IFeMSGvzR/DWKKvGVdWuYBsK FRj3xM+imyVxD8e/AbEkYW9YZm5kqG5PoSeuvk2Mqzr1KcR4qSck1AUr2/6rI6Kpurxj qMQg== X-Gm-Message-State: AC+VfDwvvn+Hqy9z18q7yuCxfwiglg5jRpaypzgXvbIAc1YEFEreaKBP FKk32aUa4qGDB2J+ER2csQ0jYXoim44PcXhVbi/wbA== X-Google-Smtp-Source: ACHHUZ6c1tU80i2NFgJWtDiNUQ4dKD46I90OznjvJZlr0ZavKr0VLoNsmAzWutpLRTPpKjM4PW0xSA6rqZaKASxRktE= X-Received: by 2002:a05:622a:5c8:b0:3ef:3361:75d5 with SMTP id d8-20020a05622a05c800b003ef336175d5mr537286qtb.11.1687834073238; Mon, 26 Jun 2023 19:47:53 -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: Yu Zhao Date: Mon, 26 Jun 2023 20:47:17 -0600 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 , 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-Stat-Signature: 7ojxphq8184wyh3ji9aq7hie6dm9q6se X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 421041C0009 X-Rspam-User: X-HE-Tag: 1687834074-49606 X-HE-Meta: U2FsdGVkX196fwKdkerv29TKMbmT9Haa5TI+ogH4uccZ48jJVc3YWxCNgODeLSsfb6TOJd+ff/ChYGMZeGQ615N0zRl48SncSyeFI6H2VDwN5B8sy96RSxxN5cGZnPJ0+XCbgT+WzII1es2Yi1lxO8NG5u5QcNOhhsZeVfvgUpUKwKmriHKdN/wCESBGgiAyB4J/zX4YFG6X9z9G95QrMcRNNBQpmPkiqJ8YSVenlR1Xne0hPH4XP/+qQWMnJlId9db3jVyRxpG13KD1OkHgcRZaLwdECtcATOLuHQto6z7vZaMml3kO7XKDNa73gukb5pJ8+EjrIiFPMImR4bugEjtw5Og5s046KX5uE5V26OXnMomrSkBgWHSqNagmLv3buZ4Cmc+sBRzOcVjI+4yqbLXBRkpFXmal/9qn9n/1KzJHDC8YMk2BjtxNySsgNwui22pTlvPe8uM0r6C1zK7tsDkTcNTY0FoSMjtV5XNyxwMnl4qdiY/L9A49yCYCM+CIdfGT++2dHP1Ge3x3gRyMRanJDxmmwwgI3vYPdXqVZPF6Deu2oDcBJ5VoHQUseJBhxi4vuNdPx+18aZDoKs43PBgDTYN0tTAIq9uqMxc2p/i2wyfAFGJsjMOKI5wzJdro17P/3ope8xDQoOjQShBMrfGL6Lu7b7ml4trncCMGk1hbhREHiMA7ased2htWdtzo61kCVoKl0pnSLmQyNnkS1/MAR9sSDdMbdoLmwwasj6A61JckuMbU09Z/Uiq/T43cK3VsFoEyhPHOsf42WJbIIb1qkqrwuo6OQr/pVnwmijGkSzW2QRlMFhwzeL052DgTgS8XT5wtmqRVt0FuBCkTUexIT/cEMSpN+m4MZsDW955C/gTzsFgoUz1xadyJd6IiJd5FdTs4R01uqrUXw/cnDXbgaACXzvcLQEluTwozFSlwqn1dmcrrZSQqgWXjMXcIIhAfCS80EuTZ9JvjLga biJD2eJg RKwns5TqbGhhPdy+khQlGf5vbriqidLNvD4kn4qiLRUVbWh2j+RzSjxUpW/SsAAB3mF13NJsEsEyhpaoufA3KkjDPdw72z0XJ7o6oVVyiNbXvHNMYlgWNZVjsNxuYdOTggcqxIGNvEEVxNsbK7jFe/wu8h+zmHFx83Znu7ndv2JQe83y2FoNCsAp0SRaD31s4TC8ijBrrm5yMDph2lyEUQOmZsp/EYWhTDK2/4VR0DF136wZXh2B/t6o7xM+VrgGcCI1ONLszh6iezf3h6Et+FnvVIAGLiCc9uxPH 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 11: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 > + > endmenu I don't think an MVP should add this many Kconfigs. One Kconfig sounds reasonable to me for now.