[PATCH v8 05/14] mm: multi-gen LRU: groundwork

[Linus Torvalds]

I still think this part is fundamentally wrong:

On Tue, Mar 8, 2022 at 3:48 PM Yu Zhao <yuzhao at google.com> wrote:
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 3326ee3903f3..4ef67f157374 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -892,6 +892,28 @@ config ANON_VMA_NAME
>           area from being merged with adjacent virtual memory areas due to the
>           difference in their name.
>
> +# the multi-gen LRU {
> +config LRU_GEN
> +       bool "Multi-Gen LRU"
> +       depends on MMU
> +       # the following options can use up the spare bits in page flags
> +       depends on !MAXSMP && (64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP)
> +       help
> +         A high performance LRU implementation for memory overcommit.
> +
> +config NR_LRU_GENS
> +       int "Max number of generations"
> +       depends on LRU_GEN
> +       range 4 31
> +       default 4
> +       help
> +         Do not increase this value unless you plan to use working set
> +         estimation and proactive reclaim. These features are usually for job
> +         scheduling optimizations in data centers.
> +
> +         This option uses order_base_2(N+1) bits in page flags.
> +# }

Pick a value. Don't ask a user for a value.

If you don't know what the value should be, the user sure as hell doesn't.

And if you don't pick a value for people to test, then people will
test random values and dilute and make the testing less valid in the
process.

There is absolutely no upside to asking people a question like this,
and only downsides.

If the quoted "schedulign optimizations" are real, then maybe bigger
values should be the default? Or maybe it should be a run-time
tunable, so that people can actually _test_ them?

Or - more likely - that config variable just shouldn't exist, at least
in some initial series, and you just should say "we use four
generations, we can tweak this if people have hard numbers later".

                 Linus