[PATCH v1 0/4] mm/ksm: Add ksm advisor

[PATCH v1 0/4] mm/ksm: Add ksm advisor

[Stefan Roesch]

What is the KSM advisor?
=========================
The ksm advisor automatically manages the pages_to_scan setting to
achieve a target scan time. The target scan time defines how many seconds
it should take to scan all the candidate KSM pages. In other words the
pages_to_scan rate is changed by the advisor to achieve the target scan
time.

Why do we need a KSM advisor?
==============================
The number of candidate pages for KSM is dynamic. It can often be observed
that during the startup of an application more candidate pages need to be
processed. Without an advisor the pages_to_scan parameter needs to be
sized for the maximum number of candidate pages. With the scan time
advisor the pages_to_scan parameter based can be changed based on demand.

Algorithm
==========
The algorithm calculates the change value based on the target scan time
and the previous scan time. To avoid pertubations an exponentially
weighted moving average is applied.

The algorithm has a max and min
value to:
- guarantee responsiveness to changes
- to avoid to spend too much CPU

Parameters to influence the KSM scan advisor
=============================================
The respective parameters are:
- ksm_advisor_mode
  0: None (default), 1: scan time advisor
- ksm_advisor_target_scan_time
  how many seconds a scan should of all candidate pages take
- ksm_advisor_min_pages
  minimum value for pages_to_scan per batch
- ksm_advisor_max_pages
  maximum value for pages_to_scan per batch

The parameters are exposed as knobs in /sys/kernel/mm/ksm.
By default the scan time advisor is disabled.

Currently there are two advisors:
- none and
- scan time.

Resource savings
=================
Tests with various workloads have shown considerable CPU savings. Most
of the workloads I have investigated have more candidate pages during
startup, once the workload is stable in terms of memory, the number of
candidate pages is reduced. Without the advisor, the pages_to_scan needs
to be sized for the maximum number of candidate pages. So having this
advisor definitely helps in reducing CPU consumption.

For the instagram workload, the advisor achieves a 25% CPU reduction.
Once the memory is stable, the pages_to_scan parameter gets reduced to
about 40% of its max value.

The new advisor works especially well if the smart scan feature is also
enabled.

How is defining a target scan time better?
===========================================
For an administrator it is more logical to set a target scan time.. The
administrator can determine how many pages are scanned on each scan.
Therefore setting a target scan time makes more sense.

In addition the administrator might have a good idea about the
memory sizing of its respective workloads.

The pages_to_scan parameter is per batch. But the administrator has
no insight how many batches are needed per scan.

Tracing
=======
A new tracing event has been added for the scan time advisor. The new
trace event is called ksm_advisor. It reports the scan time and the new
pages_to_scan setting.

Other approaches
=================

Approach 1: Adapt pages_to_scan after processing each batch. If KSM
  merges pages, increase the scan rate, if less KSM pages, reduce the
  the pages_to_scan rate. This doesn't work too well. While it increases
  the pages_to_scan for a short period, but generally it ends up with a
  too low pages_to_scan rate.

Approach 2: Adapt pages_to_scan after each scan. The problem with that
  approach is that the calculated scan rate tends to be high. The more
  aggressive KSM scans, the more pages it can de-duplicate.

There have been earlier attempts at an advisor:
  propose auto-run mode of ksm and its tests
  (https://marc.info/?l=linux-mm&m=166029880214485&w=2)



Stefan Roesch (4):
  mm/ksm: add ksm advisor
  mm/ksm: add sysfs knobs for advisor
  mm/ksm: add tracepoint for ksm advisor
  mm/ksm: document ksm advisor and its sysfs knobs

 Documentation/admin-guide/mm/ksm.rst |  45 +++++
 include/trace/events/ksm.h           |  28 ++++
 mm/ksm.c                             | 242 ++++++++++++++++++++++++++-
 3 files changed, 314 insertions(+), 1 deletion(-)


base-commit: 12d04a7bf0da67321229d2bc8b1a7074d65415a9
-- 
2.39.3

[PATCH v1 1/4] mm/ksm: add ksm advisor

[Stefan Roesch]

This adds the ksm advisor. The ksm advisor automatically manages the
pages_to_scan setting to achieve a target scan time. The target scan
time defines how many seconds it should take to scan all the candidate
KSM pages. In other words the pages_to_scan rate is changed by the
advisor to achieve the target scan time. The algorithm has a max and min
value to:
- guarantee responsiveness to changes
- to avoid to spend too much CPU

The respective parameters are:
- ksm_advisor_target_scan_time (how many seconds a scan should take)
- ksm_advisor_min_pages (minimum value for pages_to_scan per batch)
- ksm_advisor_max_pages (maximum valoe for pages_to_scan per batch)

The algorithm calculates the change value based on the target scan time
and the previous scan time. To avoid pertubations an exponentially
weighted moving average is applied.

By default the advisor is disabled. Currently there are two advisors:
none and scan_time.

Tests with various workloads have shown considerable CPU savings. Most
of the workloads I have investigated have more candidate pages during
startup, once the workload is stable in terms of memory, the number of
candidate pages is reduced. Without the advisor, the pages_to_scan needs
to be sized for the maximum number of candidate pages. So having this
advisor definitely helps in reducing CPU consumption.

For the instagram workload, the advisor achieves a 25% CPU reduction.
Once the memory is stable, the pages_to_scan parameter gets reduced to
about 40% of its max value.

Signed-off-by: Stefan Roesch <shr@devkernel.io>
---
 mm/ksm.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 131 insertions(+), 1 deletion(-)

diff --git a/mm/ksm.c b/mm/ksm.c
index 7efcc68ccc6e..c9edfb293024 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -248,6 +248,9 @@ static struct kmem_cache *rmap_item_cache;
 static struct kmem_cache *stable_node_cache;
 static struct kmem_cache *mm_slot_cache;
 
+/* Default number of pages to scan per batch */
+#define DEFAULT_PAGES_TO_SCAN 100
+
 /* The number of pages scanned */
 static unsigned long ksm_pages_scanned;
 
@@ -276,7 +279,7 @@ static unsigned int ksm_stable_node_chains_prune_millisecs = 2000;
 static int ksm_max_page_sharing = 256;
 
 /* Number of pages ksmd should scan in one batch */
-static unsigned int ksm_thread_pages_to_scan = 100;
+static unsigned int ksm_thread_pages_to_scan = DEFAULT_PAGES_TO_SCAN;
 
 /* Milliseconds ksmd should sleep between batches */
 static unsigned int ksm_thread_sleep_millisecs = 20;
@@ -297,6 +300,129 @@ unsigned long ksm_zero_pages;
 /* The number of pages that have been skipped due to "smart scanning" */
 static unsigned long ksm_pages_skipped;
 
+/* At least scan this many pages per batch. */
+static unsigned long ksm_advisor_min_pages = 500;
+
+/* Don't scan more than max pages per batch. */
+static unsigned long ksm_advisor_max_pages = 5000;
+
+/* Target scan time in seconds to analyze all KSM candidate pages. */
+static unsigned long ksm_advisor_target_scan_time = 200;
+
+/* Exponentially weighted moving average. */
+#define EWMA_WEIGHT 50
+
+/**
+ * struct advisor_ctx - metadata for KSM advisor
+ * @start_scan: start time of the current scan
+ * @scan_time: scan time of previous scan
+ * @change: change in percent to pages_to_scan parameter
+ */
+struct advisor_ctx {
+	ktime_t start_scan;
+	s64 scan_time;
+	unsigned long change;
+};
+static struct advisor_ctx advisor_ctx;
+
+/* Define different advisor's */
+enum ksm_advisor_type {
+	KSM_ADVISOR_NONE,
+	KSM_ADVISOR_FIRST = KSM_ADVISOR_NONE,
+	KSM_ADVISOR_SCAN_TIME,
+	KSM_ADVISOR_LAST = KSM_ADVISOR_SCAN_TIME
+};
+static enum ksm_advisor_type ksm_advisor;
+
+static void init_advisor(void)
+{
+	advisor_ctx.start_scan = 0;
+	advisor_ctx.scan_time = 0;
+	advisor_ctx.change = 0;
+}
+
+/*
+ * Use previous scan time if available, otherwise use current scan time as an
+ * approximation for the previous scan time.
+ */
+static inline s64 prev_scan_time(struct advisor_ctx *ctx, s64 new_scan_time)
+{
+	return ctx->scan_time ? ctx->scan_time : new_scan_time;
+}
+
+/* Calculate exponential weighted moving average */
+static unsigned long ewma(unsigned long prev, unsigned long curr)
+{
+	return ((100 - EWMA_WEIGHT) * prev + EWMA_WEIGHT * curr) / 100;
+}
+
+/*
+ * The scan time advisor is based on the current scan rate and the target
+ * scan rate.
+ *
+ *      new_pages_to_scan = pages_to_scan * (scan_time / target_scan_time)
+ *
+ * To avoid pertubations it calculates a change factor of previous changes.
+ * A new change factor is calculated for each iteration and it uses an
+ * exponentially weighted moving average. The new pages_to_scan value is
+ * multiplied with that change factor:
+ *
+ *      new_pages_to_scan *= change facor
+ *
+ * In addition the new pages_to_scan value is capped by the max and min
+ * limits.
+ */
+static void scan_time_advisor(s64 scan_time)
+{
+	unsigned long pages;
+	unsigned long factor;
+	unsigned long change;
+	unsigned long last_scan_time;
+
+	pages		= ksm_thread_pages_to_scan;
+	last_scan_time	= prev_scan_time(&advisor_ctx, scan_time);
+
+	/* Calculate scan time as percentage of target scan time */
+	factor = ksm_advisor_target_scan_time * 100 / scan_time;
+	factor = factor ? factor : 1;
+
+	/*
+	 * Calculate scan time as percentage of last scan time and use
+	 * exponentially weighted average to smooth it
+	 */
+	change = scan_time * 100 / last_scan_time;
+	change = change ? change : 1;
+	change = ewma(advisor_ctx.change, change);
+
+	/* Calculate new scan rate based on target scan rate. */
+	pages = pages * 100 / factor;
+	/* Update pages_to_scan by weighted change percentage. */
+	pages = pages * change / 100;
+
+	/* Cap new pages_to_scan value */
+	pages = max(pages, ksm_advisor_min_pages);
+	pages = min(pages, ksm_advisor_max_pages);
+
+	/* Update advisor context */
+	advisor_ctx.change = change;
+	advisor_ctx.scan_time = scan_time;
+	ksm_thread_pages_to_scan = pages;
+}
+
+static void run_advisor(void)
+{
+	if (ksm_advisor == KSM_ADVISOR_SCAN_TIME) {
+		s64 scan_time;
+
+		/* Convert scan time to seconds */
+		scan_time = ktime_ms_delta(ktime_get(), advisor_ctx.start_scan);
+		scan_time /= MSEC_PER_SEC;
+		scan_time = scan_time ? scan_time : 1;
+
+		scan_time_advisor(scan_time);
+	}
+}
+
 #ifdef CONFIG_NUMA
 /* Zeroed when merging across nodes is not allowed */
 static unsigned int ksm_merge_across_nodes = 1;
@@ -2401,6 +2527,7 @@ static struct ksm_rmap_item *scan_get_next_rmap_item(struct page **page)
 
 	mm_slot = ksm_scan.mm_slot;
 	if (mm_slot == &ksm_mm_head) {
+		advisor_ctx.start_scan = ktime_get();
 		trace_ksm_start_scan(ksm_scan.seqnr, ksm_rmap_items);
 
 		/*
@@ -2558,6 +2685,8 @@ static struct ksm_rmap_item *scan_get_next_rmap_item(struct page **page)
 	if (mm_slot != &ksm_mm_head)
 		goto next_mm;
 
+	run_advisor();
+
 	trace_ksm_stop_scan(ksm_scan.seqnr, ksm_rmap_items);
 	ksm_scan.seqnr++;
 	return NULL;
@@ -3603,6 +3732,7 @@ static int __init ksm_init(void)
 	zero_checksum = calc_checksum(ZERO_PAGE(0));
 	/* Default to false for backwards compatibility */
 	ksm_use_zero_pages = false;
+	init_advisor();
 
 	err = ksm_slab_init();
 	if (err)
-- 
2.39.3

[PATCH v1 2/4] mm/ksm: add sysfs knobs for advisor

[Stefan Roesch]

This adds four new knobs for the KSM advisor to influence its behaviour.
The knobs are:

- advisor_mode:
    0: no advisor (default)
    1: scan time advisor
- advisor_min_pages: 500 (default)
- advisor_max_pages: 5000 (default)
- advisor_target_scan_time: 200 (default in seconds)

The new values will take effect on the next scan round.

Signed-off-by: Stefan Roesch <shr@devkernel.io>
---
 mm/ksm.c | 108 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/mm/ksm.c b/mm/ksm.c
index c9edfb293024..12e70f806b2b 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -341,6 +341,14 @@ static void init_advisor(void)
 	advisor_ctx.change = 0;
 }
 
+static void set_advisor_defaults(void)
+{
+	if (ksm_advisor == KSM_ADVISOR_NONE)
+		ksm_thread_pages_to_scan = DEFAULT_PAGES_TO_SCAN;
+	else if (ksm_advisor == KSM_ADVISOR_SCAN_TIME)
+		ksm_thread_pages_to_scan = ksm_advisor_min_pages;
+}
+
 /*
  * Use previous scan time if available, otherwise use current scan time as an
  * approximation for the previous scan time.
@@ -3692,6 +3700,102 @@ static ssize_t smart_scan_store(struct kobject *kobj,
 }
 KSM_ATTR(smart_scan);
 
+static ssize_t advisor_mode_show(struct kobject *kobj,
+				 struct kobj_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "%u\n", ksm_advisor);
+}
+
+static ssize_t advisor_mode_store(struct kobject *kobj,
+				  struct kobj_attribute *attr, const char *buf,
+				  size_t count)
+{
+	unsigned int mode;
+	int err;
+
+	err = kstrtouint(buf, 10, &mode);
+	if (err)
+		return -EINVAL;
+	if (mode > KSM_ADVISOR_LAST)
+		return -EINVAL;
+
+	/* Set advisor default values */
+	ksm_advisor = mode;
+	init_advisor();
+	set_advisor_defaults();
+
+	return count;
+}
+KSM_ATTR(advisor_mode);
+
+static ssize_t advisor_min_pages_show(struct kobject *kobj,
+				      struct kobj_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "%lu\n", ksm_advisor_min_pages);
+}
+
+static ssize_t advisor_min_pages_store(struct kobject *kobj,
+				       struct kobj_attribute *attr,
+				       const char *buf, size_t count)
+{
+	int err;
+	unsigned long value;
+
+	err = kstrtoul(buf, 10, &value);
+	if (err)
+		return -EINVAL;
+
+	ksm_advisor_min_pages = value;
+	return count;
+}
+KSM_ATTR(advisor_min_pages);
+
+static ssize_t advisor_max_pages_show(struct kobject *kobj,
+				      struct kobj_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "%lu\n", ksm_advisor_max_pages);
+}
+
+static ssize_t advisor_max_pages_store(struct kobject *kobj,
+				       struct kobj_attribute *attr,
+				       const char *buf, size_t count)
+{
+	int err;
+	unsigned long value;
+
+	err = kstrtoul(buf, 10, &value);
+	if (err)
+		return -EINVAL;
+
+	ksm_advisor_max_pages = value;
+	return count;
+}
+KSM_ATTR(advisor_max_pages);
+
+static ssize_t advisor_target_scan_time_show(struct kobject *kobj,
+					     struct kobj_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "%lu\n", ksm_advisor_target_scan_time);
+}
+
+static ssize_t advisor_target_scan_time_store(struct kobject *kobj,
+					      struct kobj_attribute *attr,
+					      const char *buf, size_t count)
+{
+	int err;
+	unsigned long value;
+
+	err = kstrtoul(buf, 10, &value);
+	if (err)
+		return -EINVAL;
+	if (value < 1)
+		return -EINVAL;
+
+	ksm_advisor_target_scan_time = value;
+	return count;
+}
+KSM_ATTR(advisor_target_scan_time);
+
 static struct attribute *ksm_attrs[] = {
 	&sleep_millisecs_attr.attr,
 	&pages_to_scan_attr.attr,
@@ -3714,6 +3818,10 @@ static struct attribute *ksm_attrs[] = {
 	&use_zero_pages_attr.attr,
 	&general_profit_attr.attr,
 	&smart_scan_attr.attr,
+	&advisor_mode_attr.attr,
+	&advisor_min_pages_attr.attr,
+	&advisor_max_pages_attr.attr,
+	&advisor_target_scan_time_attr.attr,
 	NULL,
 };
 
-- 
2.39.3

Re: [PATCH v1 2/4] mm/ksm: add sysfs knobs for advisor

[kernel test robot]

Hi Stefan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 12d04a7bf0da67321229d2bc8b1a7074d65415a9]

url:    https://github.com/intel-lab-lkp/linux/commits/Stefan-Roesch/mm-ksm-add-ksm-advisor/20231005-030402
base:   12d04a7bf0da67321229d2bc8b1a7074d65415a9
patch link:    https://lore.kernel.org/r/20231004190249.829015-3-shr%40devkernel.io
patch subject: [PATCH v1 2/4] mm/ksm: add sysfs knobs for advisor
config: i386-buildonly-randconfig-002-20231006 (https://download.01.org/0day-ci/archive/20231006/202310060119.K002rbE5-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231006/202310060119.K002rbE5-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202310060119.K002rbE5-lkp@intel.com/

All errors (new ones prefixed by >>):

   ld: mm/ksm.o: in function `scan_get_next_rmap_item':
>> ksm.c:(.text+0x3e45): undefined reference to `__divdi3'
>> ld: ksm.c:(.text+0x3e88): undefined reference to `__divdi3'
   ld: ksm.c:(.text+0x3ed9): undefined reference to `__divdi3'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v1 2/4] mm/ksm: add sysfs knobs for advisor

[kernel test robot]

Hi Stefan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 12d04a7bf0da67321229d2bc8b1a7074d65415a9]

url:    https://github.com/intel-lab-lkp/linux/commits/Stefan-Roesch/mm-ksm-add-ksm-advisor/20231005-030402
base:   12d04a7bf0da67321229d2bc8b1a7074d65415a9
patch link:    https://lore.kernel.org/r/20231004190249.829015-3-shr%40devkernel.io
patch subject: [PATCH v1 2/4] mm/ksm: add sysfs knobs for advisor
config: arm-randconfig-001-20231006 (https://download.01.org/0day-ci/archive/20231006/202310060504.eMl8wb3o-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231006/202310060504.eMl8wb3o-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202310060504.eMl8wb3o-lkp@intel.com/

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: mm/ksm.o: in function `run_advisor':
>> ksm.c:(.text+0x21e8): undefined reference to `__aeabi_ldivmod'
>> arm-linux-gnueabi-ld: ksm.c:(.text+0x2290): undefined reference to `__aeabi_ldivmod'
   arm-linux-gnueabi-ld: ksm.c:(.text+0x22cc): undefined reference to `__aeabi_ldivmod'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v1 3/4] mm/ksm: add tracepoint for ksm advisor

[Stefan Roesch]

This adds a new tracepoint for the ksm advisor. It reports the last scan
time and the new setting of the pages_to_scan parameter.

Signed-off-by: Stefan Roesch <shr@devkernel.io>
---
 include/trace/events/ksm.h | 28 ++++++++++++++++++++++++++++
 mm/ksm.c                   |  2 ++
 2 files changed, 30 insertions(+)

diff --git a/include/trace/events/ksm.h b/include/trace/events/ksm.h
index b5ac35c1d0e8..164133014922 100644
--- a/include/trace/events/ksm.h
+++ b/include/trace/events/ksm.h
@@ -245,6 +245,34 @@ TRACE_EVENT(ksm_remove_rmap_item,
 			__entry->pfn, __entry->rmap_item, __entry->mm)
 );
 
+/**
+ * ksm_advisor - called after the advisor has run
+ *
+ * @scan_time:		scan time in seconds
+ * @pages_to_scan:	new pages_to_scan value
+ *
+ * Allows to trace the ksm advisor.
+ */
+TRACE_EVENT(ksm_advisor,
+
+	TP_PROTO(s64 scan_time, unsigned long pages_to_scan),
+
+	TP_ARGS(scan_time, pages_to_scan),
+
+	TP_STRUCT__entry(
+		__field(s64,		scan_time)
+		__field(unsigned long,	pages_to_scan)
+	),
+
+	TP_fast_assign(
+		__entry->scan_time	= scan_time;
+		__entry->pages_to_scan	= pages_to_scan;
+	),
+
+	TP_printk("ksm scan time %lld pages_to_scan %lu",
+			__entry->scan_time, __entry->pages_to_scan)
+);
+
 #endif /* _TRACE_KSM_H */
 
 /* This part must be outside protection */
diff --git a/mm/ksm.c b/mm/ksm.c
index 12e70f806b2b..93dff974f6ea 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -415,6 +415,8 @@ static void scan_time_advisor(s64 scan_time)
 	advisor_ctx.change = change;
 	advisor_ctx.scan_time = scan_time;
 	ksm_thread_pages_to_scan = pages;
+
+	trace_ksm_advisor(scan_time, pages);
 }
 
 static void run_advisor(void)
-- 
2.39.3

[PATCH v1 4/4] mm/ksm: document ksm advisor and its sysfs knobs

[Stefan Roesch]

This documents the KSM advisor and its new knobs in /sys/fs/kernel/mm.

Signed-off-by: Stefan Roesch <shr@devkernel.io>
---
 Documentation/admin-guide/mm/ksm.rst | 45 ++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index e59231ac6bb7..8de93650d3b0 100644
--- a/Documentation/admin-guide/mm/ksm.rst
+++ b/Documentation/admin-guide/mm/ksm.rst
@@ -164,6 +164,25 @@ smart_scan
         optimization is enabled.  The ``pages_skipped`` metric shows how
         effective the setting is.
 
+advisor_mode
+        The ``advisor_mode`` selects the current advisor. Two modes are
+        supported: 0 (None) and 1 (Scan time). The default is None. By
+        setting ``advisor_mode`` to 1, the scan time advisor is enabled.
+        The section about ``advisor`` explains in detail how the scan time
+        advisor works.
+
+advisor_min_pages
+        specifies the lower limit of the ``pages_to_scan`` parameter of the
+        scan time advisor. The default is 500.
+
+adivsor_max_pages
+        specifies the upper limit of the ``pages_to_scan`` parameter of the
+        scan time advisor. The default is 5000.
+
+advisor_target_scan_time
+        specifies the target scan time in seconds to scan all the candidate
+        pages. The default value is 200 seconds.
+
 The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
 
 general_profit
@@ -263,6 +282,32 @@ ksm_swpin_copy
 	note that KSM page might be copied when swapping in because do_swap_page()
 	cannot do all the locking needed to reconstitute a cross-anon_vma KSM page.
 
+Advisor
+=======
+
+The number of candidate pages for KSM is dynamic. It can be often observed
+that during the startup of an application more candidate pages need to be
+processed. Without an advisor the ``pages_to_scan`` parameter needs to be
+sized for the maximum number of candidate pages. The scan time advisor can
+changes the ``pages_to_scan`` parameter based on demand.
+
+The advisor can be enabled so KSM can automatically adapt to changes in the
+number of candidate pages to scan. Two advisors are implemented: 0 (None) and
+1 (Scan time). With None no advisor is enabled. The default is None.
+
+The Scan time advisor changes the ``pages_to_scan`` parameter based on the
+observed scan times. The possible values for the ``pages_to_scan`` parameter is
+limited by the ``advisor_min_pages`` and ``advisor_max_pages`` parameters. In
+addition there is also the ``advisor_target_scan_time`` parameter. This
+parameter sets the target time to scan all the KSM candidate pages. The
+parameter ``advisor_target_scan_time`` decides how aggressive the scan time
+advisor scans candidate pages. Lower values make the scan time advisor to scan
+more aggresively. This is the most important parameter for the configuration of
+the scan time advisor.
+
+The ``pages_to_scan`` parameter is re-calculated after a scan has been completed.
+
+
 --
 Izik Eidus,
 Hugh Dickins, 17 Nov 2009
-- 
2.39.3

Re: [PATCH v1 0/4] mm/ksm: Add ksm advisor

[David Hildenbrand]

On 04.10.23 21:02, Stefan Roesch wrote:
> What is the KSM advisor?
> =========================
> The ksm advisor automatically manages the pages_to_scan setting to
> achieve a target scan time. The target scan time defines how many seconds
> it should take to scan all the candidate KSM pages. In other words the
> pages_to_scan rate is changed by the advisor to achieve the target scan
> time.
> 
> Why do we need a KSM advisor?
> ==============================
> The number of candidate pages for KSM is dynamic. It can often be observed
> that during the startup of an application more candidate pages need to be
> processed. Without an advisor the pages_to_scan parameter needs to be
> sized for the maximum number of candidate pages. With the scan time
> advisor the pages_to_scan parameter based can be changed based on demand.
> 
> Algorithm
> ==========
> The algorithm calculates the change value based on the target scan time
> and the previous scan time. To avoid pertubations an exponentially
> weighted moving average is applied.
> 
> The algorithm has a max and min
> value to:
> - guarantee responsiveness to changes
> - to avoid to spend too much CPU
> 
> Parameters to influence the KSM scan advisor
> =============================================
> The respective parameters are:
> - ksm_advisor_mode
>    0: None (default), 1: scan time advisor
> - ksm_advisor_target_scan_time
>    how many seconds a scan should of all candidate pages take
> - ksm_advisor_min_pages
>    minimum value for pages_to_scan per batch
> - ksm_advisor_max_pages
>    maximum value for pages_to_scan per batch
> 
> The parameters are exposed as knobs in /sys/kernel/mm/ksm.
> By default the scan time advisor is disabled.

What would be the main reason to not have this enabled as default?

IIUC, it is kind-of an auto-tuning of pages_to_scan. Would "auto-tuning" 
describe it better than "advisor" ?

[...]

> How is defining a target scan time better?
> ===========================================
> For an administrator it is more logical to set a target scan time.. The
> administrator can determine how many pages are scanned on each scan.
> Therefore setting a target scan time makes more sense.
> 
> In addition the administrator might have a good idea about the
> memory sizing of its respective workloads.

Is there any way you could imagine where we could have this just do 
something reasonable without any user input? IOW, true auto-tuning?

I read above:
 > - guarantee responsiveness to changes
 > - to avoid to spend too much CPU

whereby both things are accountable/measurable to use that as the input 
for auto-tuning?


I just had a family NMI, so my todo list is quite lengthy. Hoping I cna 
take a closer look next week.

-- 
Cheers,

David / dhildenb

Re: [PATCH v1 0/4] mm/ksm: Add ksm advisor

[Stefan Roesch]

David Hildenbrand <david@redhat.com> writes:

> On 04.10.23 21:02, Stefan Roesch wrote:
>> What is the KSM advisor?
>> =========================
>> The ksm advisor automatically manages the pages_to_scan setting to
>> achieve a target scan time. The target scan time defines how many seconds
>> it should take to scan all the candidate KSM pages. In other words the
>> pages_to_scan rate is changed by the advisor to achieve the target scan
>> time.
>> Why do we need a KSM advisor?
>> ==============================
>> The number of candidate pages for KSM is dynamic. It can often be observed
>> that during the startup of an application more candidate pages need to be
>> processed. Without an advisor the pages_to_scan parameter needs to be
>> sized for the maximum number of candidate pages. With the scan time
>> advisor the pages_to_scan parameter based can be changed based on demand.
>> Algorithm
>> ==========
>> The algorithm calculates the change value based on the target scan time
>> and the previous scan time. To avoid pertubations an exponentially
>> weighted moving average is applied.
>> The algorithm has a max and min
>> value to:
>> - guarantee responsiveness to changes
>> - to avoid to spend too much CPU
>> Parameters to influence the KSM scan advisor
>> =============================================
>> The respective parameters are:
>> - ksm_advisor_mode
>>    0: None (default), 1: scan time advisor
>> - ksm_advisor_target_scan_time
>>    how many seconds a scan should of all candidate pages take
>> - ksm_advisor_min_pages
>>    minimum value for pages_to_scan per batch
>> - ksm_advisor_max_pages
>>    maximum value for pages_to_scan per batch
>> The parameters are exposed as knobs in /sys/kernel/mm/ksm.
>> By default the scan time advisor is disabled.
>
> What would be the main reason to not have this enabled as default?
>
There might be already exisiting users which directly set pages_to_scan
and tuned the KSM settings accordingly, as the default setting of 100 for
pages_to_scan is too low for typical workloads.

> IIUC, it is kind-of an auto-tuning of pages_to_scan. Would "auto-tuning"
> describe it better than "advisor" ?
>
> [...]
>

I'm fine with auto-tune. I was also thinking about that name, but I
chose advisor, its a bit less strong and it needs input from the user.

>> How is defining a target scan time better?
>> ===========================================
>> For an administrator it is more logical to set a target scan time.. The
>> administrator can determine how many pages are scanned on each scan.
>> Therefore setting a target scan time makes more sense.
>> In addition the administrator might have a good idea about the
>> memory sizing of its respective workloads.
>
> Is there any way you could imagine where we could have this just do something
> reasonable without any user input? IOW, true auto-tuning?
>

True auto-tuning might be difficult as users might want to be able to
choose how aggressive KSM is. Some might want it to be as aggressive as
possible to get the maximum de-duplication rate. Others might want a
more balanced approach that takes CPU-consumption into consideration.

I guess it depends if you are memory-bound, cpu-bound or both.

> I read above:
>> - guarantee responsiveness to changes
>> - to avoid to spend too much CPU
>
> whereby both things are accountable/measurable to use that as the input for
> auto-tuning?
>
I'm not sure a true auto-tuning can be achieved. I think we need
some input from the user
- How much resources to consume
- How fast memory changes or how stable memory is
  (this we might be able to detect)

>
>
> I just had a family NMI, so my todo list is quite lengthy. Hoping I cna take a
> closer look next week.

Re: [PATCH v1 0/4] mm/ksm: Add ksm advisor

[David Hildenbrand]

On 06.10.23 18:17, Stefan Roesch wrote:
> 
> David Hildenbrand <david@redhat.com> writes:
> 
>> On 04.10.23 21:02, Stefan Roesch wrote:
>>> What is the KSM advisor?
>>> =========================
>>> The ksm advisor automatically manages the pages_to_scan setting to
>>> achieve a target scan time. The target scan time defines how many seconds
>>> it should take to scan all the candidate KSM pages. In other words the
>>> pages_to_scan rate is changed by the advisor to achieve the target scan
>>> time.
>>> Why do we need a KSM advisor?
>>> ==============================
>>> The number of candidate pages for KSM is dynamic. It can often be observed
>>> that during the startup of an application more candidate pages need to be
>>> processed. Without an advisor the pages_to_scan parameter needs to be
>>> sized for the maximum number of candidate pages. With the scan time
>>> advisor the pages_to_scan parameter based can be changed based on demand.
>>> Algorithm
>>> ==========
>>> The algorithm calculates the change value based on the target scan time
>>> and the previous scan time. To avoid pertubations an exponentially
>>> weighted moving average is applied.
>>> The algorithm has a max and min
>>> value to:
>>> - guarantee responsiveness to changes
>>> - to avoid to spend too much CPU
>>> Parameters to influence the KSM scan advisor
>>> =============================================
>>> The respective parameters are:
>>> - ksm_advisor_mode
>>>     0: None (default), 1: scan time advisor
>>> - ksm_advisor_target_scan_time
>>>     how many seconds a scan should of all candidate pages take
>>> - ksm_advisor_min_pages
>>>     minimum value for pages_to_scan per batch
>>> - ksm_advisor_max_pages
>>>     maximum value for pages_to_scan per batch
>>> The parameters are exposed as knobs in /sys/kernel/mm/ksm.
>>> By default the scan time advisor is disabled.
>>
>> What would be the main reason to not have this enabled as default?
>>
> There might be already exisiting users which directly set pages_to_scan
> and tuned the KSM settings accordingly, as the default setting of 100 for
> pages_to_scan is too low for typical workloads.

Good point.

> 
>> IIUC, it is kind-of an auto-tuning of pages_to_scan. Would "auto-tuning"
>> describe it better than "advisor" ?
>>
>> [...]
>>
> 
> I'm fine with auto-tune. I was also thinking about that name, but I
> chose advisor, its a bit less strong and it needs input from the user.
> 

I'm not a native speaker, but "adviser" to me implies that no action is 
taken, only advises are given :) But again, no native speaker.

>>> How is defining a target scan time better?
>>> ===========================================
>>> For an administrator it is more logical to set a target scan time.. The
>>> administrator can determine how many pages are scanned on each scan.
>>> Therefore setting a target scan time makes more sense.
>>> In addition the administrator might have a good idea about the
>>> memory sizing of its respective workloads.
>>
>> Is there any way you could imagine where we could have this just do something
>> reasonable without any user input? IOW, true auto-tuning?
>>
> 
> True auto-tuning might be difficult as users might want to be able to
> choose how aggressive KSM is. Some might want it to be as aggressive as
> possible to get the maximum de-duplication rate. Others might want a
> more balanced approach that takes CPU-consumption into consideration.
> 
> I guess it depends if you are memory-bound, cpu-bound or both.

Agreed, more below.

> 
>> I read above:
>>> - guarantee responsiveness to changes
>>> - to avoid to spend too much CPU
>>
>> whereby both things are accountable/measurable to use that as the input for
>> auto-tuning?
>>
> I'm not sure a true auto-tuning can be achieved. I think we need
> some input from the user
> - How much resources to consume
> - How fast memory changes or how stable memory is
>    (this we might be able to detect)

Setting the pages_to_scan is a bit mystical. Setting upper/lower 
pages_to_scan bounds is similarly mystical, and highly workload dependent.

So I agree that a better abstraction to automatically tune the scanning 
is reasonable. I wonder if we can let the user give better inputs that 
are less workload dependent.

For example, do we need min/max values for pages_to_scan, or can we 
replace it by something better to the auto-tuning algorithm?

IMHO "target scan time" goes into the right direction, but it can still 
be fairly workload dependent. Maybe a "max CPU consumption" or sth. like 
that would similarly help to limit CPU waste, and it could be fairly 
workload dependent.


-- 
Cheers,

David / dhildenb

Re: [PATCH v1 0/4] mm/ksm: Add ksm advisor

[Stefan Roesch]

David Hildenbrand <david@redhat.com> writes:

> On 06.10.23 18:17, Stefan Roesch wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> On 04.10.23 21:02, Stefan Roesch wrote:
>>>> What is the KSM advisor?
>>>> =========================
>>>> The ksm advisor automatically manages the pages_to_scan setting to
>>>> achieve a target scan time. The target scan time defines how many seconds
>>>> it should take to scan all the candidate KSM pages. In other words the
>>>> pages_to_scan rate is changed by the advisor to achieve the target scan
>>>> time.
>>>> Why do we need a KSM advisor?
>>>> ==============================
>>>> The number of candidate pages for KSM is dynamic. It can often be observed
>>>> that during the startup of an application more candidate pages need to be
>>>> processed. Without an advisor the pages_to_scan parameter needs to be
>>>> sized for the maximum number of candidate pages. With the scan time
>>>> advisor the pages_to_scan parameter based can be changed based on demand.
>>>> Algorithm
>>>> ==========
>>>> The algorithm calculates the change value based on the target scan time
>>>> and the previous scan time. To avoid pertubations an exponentially
>>>> weighted moving average is applied.
>>>> The algorithm has a max and min
>>>> value to:
>>>> - guarantee responsiveness to changes
>>>> - to avoid to spend too much CPU
>>>> Parameters to influence the KSM scan advisor
>>>> =============================================
>>>> The respective parameters are:
>>>> - ksm_advisor_mode
>>>>     0: None (default), 1: scan time advisor
>>>> - ksm_advisor_target_scan_time
>>>>     how many seconds a scan should of all candidate pages take
>>>> - ksm_advisor_min_pages
>>>>     minimum value for pages_to_scan per batch
>>>> - ksm_advisor_max_pages
>>>>     maximum value for pages_to_scan per batch
>>>> The parameters are exposed as knobs in /sys/kernel/mm/ksm.
>>>> By default the scan time advisor is disabled.
>>>
>>> What would be the main reason to not have this enabled as default?
>>>
>> There might be already exisiting users which directly set pages_to_scan
>> and tuned the KSM settings accordingly, as the default setting of 100 for
>> pages_to_scan is too low for typical workloads.
>
> Good point.
>
>>
>>> IIUC, it is kind-of an auto-tuning of pages_to_scan. Would "auto-tuning"
>>> describe it better than "advisor" ?
>>>
>>> [...]
>>>
>> I'm fine with auto-tune. I was also thinking about that name, but I
>> chose advisor, its a bit less strong and it needs input from the user.
>>
>
> I'm not a native speaker, but "adviser" to me implies that no action is taken,
> only advises are given :) But again, no native speaker.
>
>>>> How is defining a target scan time better?
>>>> ===========================================
>>>> For an administrator it is more logical to set a target scan time.. The
>>>> administrator can determine how many pages are scanned on each scan.
>>>> Therefore setting a target scan time makes more sense.
>>>> In addition the administrator might have a good idea about the
>>>> memory sizing of its respective workloads.
>>>
>>> Is there any way you could imagine where we could have this just do something
>>> reasonable without any user input? IOW, true auto-tuning?
>>>
>> True auto-tuning might be difficult as users might want to be able to
>> choose how aggressive KSM is. Some might want it to be as aggressive as
>> possible to get the maximum de-duplication rate. Others might want a
>> more balanced approach that takes CPU-consumption into consideration.
>> I guess it depends if you are memory-bound, cpu-bound or both.
>
> Agreed, more below.
>
>>
>>> I read above:
>>>> - guarantee responsiveness to changes
>>>> - to avoid to spend too much CPU
>>>
>>> whereby both things are accountable/measurable to use that as the input for
>>> auto-tuning?
>>>
>> I'm not sure a true auto-tuning can be achieved. I think we need
>> some input from the user
>> - How much resources to consume
>> - How fast memory changes or how stable memory is
>>    (this we might be able to detect)
>
> Setting the pages_to_scan is a bit mystical. Setting upper/lower pages_to_scan
> bounds is similarly mystical, and highly workload dependent.
>
> So I agree that a better abstraction to automatically tune the scanning is
> reasonable. I wonder if we can let the user give better inputs that are less
> workload dependent.
>
> For example, do we need min/max values for pages_to_scan, or can we replace it
> by something better to the auto-tuning algorithm?
>
> IMHO "target scan time" goes into the right direction, but it can still be
> fairly workload dependent. Maybe a "max CPU consumption" or sth. like that would
> similarly help to limit CPU waste, and it could be fairly workload dependent.

I can look into replacing min/max values for pages_to_scan with min/max
cpu utilization. This might be easier for users to decide on. However I
still think that we need a target value like scan time to optimize for.

Re: [PATCH v1 0/4] mm/ksm: Add ksm advisor

[David Hildenbrand]

On 10.10.23 18:02, Stefan Roesch wrote:
> 
> David Hildenbrand <david@redhat.com> writes:
> 
>> On 06.10.23 18:17, Stefan Roesch wrote:
>>> David Hildenbrand <david@redhat.com> writes:
>>>
>>>> On 04.10.23 21:02, Stefan Roesch wrote:
>>>>> What is the KSM advisor?
>>>>> =========================
>>>>> The ksm advisor automatically manages the pages_to_scan setting to
>>>>> achieve a target scan time. The target scan time defines how many seconds
>>>>> it should take to scan all the candidate KSM pages. In other words the
>>>>> pages_to_scan rate is changed by the advisor to achieve the target scan
>>>>> time.
>>>>> Why do we need a KSM advisor?
>>>>> ==============================
>>>>> The number of candidate pages for KSM is dynamic. It can often be observed
>>>>> that during the startup of an application more candidate pages need to be
>>>>> processed. Without an advisor the pages_to_scan parameter needs to be
>>>>> sized for the maximum number of candidate pages. With the scan time
>>>>> advisor the pages_to_scan parameter based can be changed based on demand.
>>>>> Algorithm
>>>>> ==========
>>>>> The algorithm calculates the change value based on the target scan time
>>>>> and the previous scan time. To avoid pertubations an exponentially
>>>>> weighted moving average is applied.
>>>>> The algorithm has a max and min
>>>>> value to:
>>>>> - guarantee responsiveness to changes
>>>>> - to avoid to spend too much CPU
>>>>> Parameters to influence the KSM scan advisor
>>>>> =============================================
>>>>> The respective parameters are:
>>>>> - ksm_advisor_mode
>>>>>      0: None (default), 1: scan time advisor
>>>>> - ksm_advisor_target_scan_time
>>>>>      how many seconds a scan should of all candidate pages take
>>>>> - ksm_advisor_min_pages
>>>>>      minimum value for pages_to_scan per batch
>>>>> - ksm_advisor_max_pages
>>>>>      maximum value for pages_to_scan per batch
>>>>> The parameters are exposed as knobs in /sys/kernel/mm/ksm.
>>>>> By default the scan time advisor is disabled.
>>>>
>>>> What would be the main reason to not have this enabled as default?
>>>>
>>> There might be already exisiting users which directly set pages_to_scan
>>> and tuned the KSM settings accordingly, as the default setting of 100 for
>>> pages_to_scan is too low for typical workloads.
>>
>> Good point.
>>
>>>
>>>> IIUC, it is kind-of an auto-tuning of pages_to_scan. Would "auto-tuning"
>>>> describe it better than "advisor" ?
>>>>
>>>> [...]
>>>>
>>> I'm fine with auto-tune. I was also thinking about that name, but I
>>> chose advisor, its a bit less strong and it needs input from the user.
>>>
>>
>> I'm not a native speaker, but "adviser" to me implies that no action is taken,
>> only advises are given :) But again, no native speaker.
>>
>>>>> How is defining a target scan time better?
>>>>> ===========================================
>>>>> For an administrator it is more logical to set a target scan time.. The
>>>>> administrator can determine how many pages are scanned on each scan.
>>>>> Therefore setting a target scan time makes more sense.
>>>>> In addition the administrator might have a good idea about the
>>>>> memory sizing of its respective workloads.
>>>>
>>>> Is there any way you could imagine where we could have this just do something
>>>> reasonable without any user input? IOW, true auto-tuning?
>>>>
>>> True auto-tuning might be difficult as users might want to be able to
>>> choose how aggressive KSM is. Some might want it to be as aggressive as
>>> possible to get the maximum de-duplication rate. Others might want a
>>> more balanced approach that takes CPU-consumption into consideration.
>>> I guess it depends if you are memory-bound, cpu-bound or both.
>>
>> Agreed, more below.
>>
>>>
>>>> I read above:
>>>>> - guarantee responsiveness to changes
>>>>> - to avoid to spend too much CPU
>>>>
>>>> whereby both things are accountable/measurable to use that as the input for
>>>> auto-tuning?
>>>>
>>> I'm not sure a true auto-tuning can be achieved. I think we need
>>> some input from the user
>>> - How much resources to consume
>>> - How fast memory changes or how stable memory is
>>>     (this we might be able to detect)
>>
>> Setting the pages_to_scan is a bit mystical. Setting upper/lower pages_to_scan
>> bounds is similarly mystical, and highly workload dependent.
>>
>> So I agree that a better abstraction to automatically tune the scanning is
>> reasonable. I wonder if we can let the user give better inputs that are less
>> workload dependent.
>>
>> For example, do we need min/max values for pages_to_scan, or can we replace it
>> by something better to the auto-tuning algorithm?
>>
>> IMHO "target scan time" goes into the right direction, but it can still be
>> fairly workload dependent. Maybe a "max CPU consumption" or sth. like that would
>> similarly help to limit CPU waste, and it could be fairly workload dependent.
> 
> I can look into replacing min/max values for pages_to_scan with min/max
> cpu utilization. This might be easier for users to decide on. However I
> still think that we need a target value like scan time to optimize for.

Agreed, it can't be completely automatic.

-- 
Cheers,

David / dhildenb