Re: [PATCH v1 08/10] mm: Kconfig hooks to determine max anon folio allocation order

Yu Zhao
2023-06-27T02:47:58Z

On Mon, Jun 26, 2023 at 11:15 AM Ryan Roberts <ryan.roberts@arm.com> 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 <ryan.roberts@arm.com>
> ---
> 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 other
> + 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.