Thread (20 messages) 20 messages, 2 authors, 2022-03-09

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2022-03-09 01:16:45
Also in: linux-doc, linux-mm, lkml

I still think this part is fundamentally wrong:

On Tue, Mar 8, 2022 at 3:48 PM Yu Zhao [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help