mm, vmacache: Add kconfig VMACACHE_SHIFT

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance.

Quoted 5 lines · WANG Chao

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance.

Nack. I don't feel comfortable making scalability features of core code configurable.

Hi, Davidlohr

Quoted 7 lines · Davidlohr Bueso

Quoted 5 lines · WANG Chao

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance.

Quoted 2 lines

Nack. I don't feel comfortable making scalability features of core code configurable.

Out of respect, is this a general rule not making scalability features of core code configurable?

Quoted 13 lines · WANG Chao

Hi, Davidlohr

Quoted 9 lines · Davidlohr Bueso

Quoted 5 lines · WANG Chao

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance.

Nack. I don't feel comfortable making scalability features of core code configurable.

Quoted 2 lines

Out of respect, is this a general rule not making scalability features of core code configurable?

I doubt its a rule, just common sense. Users have no business configuring such low level details. The optimizations need to transparently work for everyone.

Quoted 17 lines · Davidlohr Bueso

Quoted 15 lines · WANG Chao

Hi, Davidlohr

Quoted 9 lines · Davidlohr Bueso

Quoted 5 lines · WANG Chao

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance.

Nack. I don't feel comfortable making scalability features of core code configurable.

Out of respect, is this a general rule not making scalability features of core code configurable?

Quoted 3 lines

I doubt its a rule, just common sense. Users have no business configuring such low level details. The optimizations need to transparently work for everyone.

There may sometimes be a good reason for making this kind of thing configurable, but since there were no performance numbers in the changelog, I have not seen any such reason for this particular change :)

Quoted 18 lines · Rik van Riel

Quoted 18 lines · Davidlohr Bueso

Quoted 17 lines

Quoted 17 lines · WANG Chao

Quoted 15 lines

Quoted 15 lines

Hi, Davidlohr

Quoted 9 lines · Davidlohr Bueso

Quoted 9 lines · WANG Chao

Quoted 5 lines

Quoted 5 lines

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2 (4 slots) as it originally is, which provides good enough balance.

Nack. I don't feel comfortable making scalability features of core code configurable.

Out of respect, is this a general rule not making scalability features of core code configurable?

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

Quoted 3 lines

I doubt its a rule, just common sense. Users have no business configuring such low level details. The optimizations need to transparently work for everyone.

There may sometimes be a good reason for making this kind of thing configurable, but since there were no performance numbers in the changelog, I have not seen any such reason for this particular change :)

True. I didn't run any kind of benchmark, thus no numbers here. This is purely hypothetical.

I'm glad to run some tests. For the sake of consistency, could you please show me a hint how do you measure at the first place? I can do hit-rate, but I don't know how you measure cpu cycles. Could you elaborate?

Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the number of slots vma cache has for each thread. Range is chosen 0-4 (1-16 slots) to consider both overhead and performance penalty. Default is 2

(4 slots) as it originally is, which provides good enough balance.

Signed-off-by WANG Chao <[email protected]>

---
  include/linux/sched.h | 2 +-
  mm/Kconfig            | 7 +++++++
  2 files changed, 8 insertions(+), 1 deletion(-)

include/linux/sched.h +1 -1

index 8db31ef..56fd96d 100644
@@ -134,7 +134,7 @@ struct perf_event_context;
  struct blk_plug;
  struct filename;
 
-#define VMACACHE_BITS 2
+#define VMACACHE_BITS CONFIG_VMACACHE_SHIFT
  #define VMACACHE_SIZE (1U << VMACACHE_BITS)
  #define VMACACHE_MASK (VMACACHE_SIZE - 1)
 

mm/Kconfig +0 -0

index 1d1ae6b..7b82a52 100644