linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] mm/damon/sysfs: Implement recording feature
@ 2023-11-28  7:34 cuiyangpei
  2023-11-28  7:34 ` [PATCH 2/2] mm/damon/core: add sysfs nodes to set last_nr_accesses weight cuiyangpei
                   ` (3 more replies)
  0 siblings, 4 replies; 22+ messages in thread
From: cuiyangpei @ 2023-11-28  7:34 UTC (permalink / raw)
  To: sj, akpm, damon, linux-mm, linux-kernel; +Cc: cuiyangpei

The user space users can control DAMON and get the monitoring results
via implements 'recording' feature in 'damon-sysfs'.  The feature
can be used via 'record' and 'state' file in the '<sysfs>/kernel/mm/
damon/admin/kdamonds/N/' directory.

The file allows users to record monitored access patterns in a text
file. Firstly, users set the size of the buffer and the path of the
result file by writing to the ``record`` file. Then the recorded
results are first written in an in-memory buffer and flushed the
recorded results to a file in batch by writing 'record' to the
``state`` file.

For example, below commands set the buffer to be 4 KiB and the result
to be saved in ``/damon.txt``. ::

    # cd <sysfs>/kernel/mm/damon/admin/kdamonds/N
    # echo "4096 /damon.txt" > record
    # echo "record" > state

Signed-off-by: cuiyangpei <cuiyangpei@xiaomi.com>
---
 .../ABI/testing/sysfs-kernel-mm-damon         |  20 +-
 include/linux/damon.h                         |  11 +
 mm/damon/sysfs.c                              | 282 ++++++++++++++++++
 3 files changed, 307 insertions(+), 6 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index b35649a46a2f..819534dcfb6c 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -25,15 +25,23 @@ Description:	Writing 'on' or 'off' to this file makes the kdamond starts or
 		stops, respectively.  Reading the file returns the keywords
 		based on the current status.  Writing 'commit' to this file
 		makes the kdamond reads the user inputs in the sysfs files
-		except 'state' again.  Writing 'update_schemes_stats' to the
-		file updates contents of schemes stats files of the kdamond.
-		Writing 'update_schemes_tried_regions' to the file updates
-		contents of 'tried_regions' directory of every scheme directory
-		of this kdamond.  Writing 'update_schemes_tried_bytes' to the
-		file updates only '.../tried_regions/total_bytes' files of this
+		except 'state' again.  Writing 'record' to this file makes the
+		kdamond saves the monitoring results to file specified by the
+		/record file. Writing 'update_schemes_stats'to the file updates
+		contents of schemes stats files of the kdamond. Writing
+		'update_schemes_tried_regions' to the file updates contents of
+		'tried_regions' directory of every scheme directory of this
+		kdamond.  Writing 'update_schemes_tried_bytes' to the file
+		updates only '.../tried_regions/total_bytes' files of this
 		kdamond.  Writing 'clear_schemes_tried_regions' to the file
 		removes contents of the 'tried_regions' directory.
 
+What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/record
+Date:		Nov 2023
+Contact:	Ping Xiong <xiongping1@xiaomi.com>
+Description:	Writing a string '4096 /damon.txt' to this file makes the
+		user to record monitored access patterns in a text file.
+
 What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/pid
 Date:		Mar 2022
 Contact:	SeongJae Park <sj@kernel.org>
diff --git a/include/linux/damon.h b/include/linux/damon.h
index ab2f17d9926b..6495513cc6de 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -19,6 +19,17 @@
 /* Max priority score for DAMON-based operation schemes */
 #define DAMOS_MAX_SCORE		(99)
 
+#define MIN_RECORD_BUFFER_LEN	1024
+#define MAX_RECORD_BUFFER_LEN	(4 * 1024 * 1024)
+#define MAX_RFILE_PATH_LEN	256
+
+struct sysfs_recorder {
+	unsigned char *rbuf;
+	unsigned int rbuf_len;
+	unsigned int rbuf_offset;
+	char *rfile_path;
+};
+
 /* Get a random number in [l, r) */
 static inline unsigned long damon_rand(unsigned long l, unsigned long r)
 {
diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index e27846708b5a..7a7d41e609e3 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -994,6 +994,8 @@ enum damon_sysfs_cmd {
 	DAMON_SYSFS_CMD_OFF,
 	/* @DAMON_SYSFS_CMD_COMMIT: Update kdamond inputs. */
 	DAMON_SYSFS_CMD_COMMIT,
+	/* @DAMON_SYSFS_CMD_RECORD: Save the monitoring results to file. */
+	DAMON_SYSFS_CMD_RECORD,
 	/*
 	 * @DAMON_SYSFS_CMD_UPDATE_SCHEMES_STATS: Update scheme stats sysfs
 	 * files.
@@ -1025,6 +1027,7 @@ static const char * const damon_sysfs_cmd_strs[] = {
 	"on",
 	"off",
 	"commit",
+	"record",
 	"update_schemes_stats",
 	"update_schemes_tried_bytes",
 	"update_schemes_tried_regions",
@@ -1349,6 +1352,160 @@ static int damon_sysfs_commit_input(struct damon_sysfs_kdamond *kdamond)
 			kdamond->contexts->contexts_arr[0]);
 }
 
+/*
+ * Flush the content in the result buffer to the result file
+ */
+static int sysfs_flush_rbuffer(struct sysfs_recorder *rec)
+{
+	ssize_t sz;
+	loff_t pos = 0;
+	struct file *rfile;
+
+	if (!rec->rbuf_offset)
+		return 0;
+
+	rfile = filp_open(rec->rfile_path,
+			O_CREAT | O_RDWR | O_APPEND | O_LARGEFILE, 0644);
+	if (IS_ERR(rfile)) {
+		pr_err("Cannot open the result file %s\n",
+				rec->rfile_path);
+		return PTR_ERR(rfile);
+	}
+
+	while (rec->rbuf_offset) {
+		sz = kernel_write(rfile, rec->rbuf, rec->rbuf_offset, &pos);
+		if (sz < 0) {
+			filp_close(rfile, NULL);
+			return sz;
+		}
+		rec->rbuf_offset -= sz;
+	}
+	filp_close(rfile, NULL);
+
+	return 0;
+}
+
+/*
+ * Write a data into the result buffer
+ */
+static void sysfs_write_rbuf(struct damon_ctx *ctx, char *data, int size)
+{
+	struct sysfs_recorder *rec = ctx->callback.private;
+
+	if (!rec->rbuf_len || !rec->rbuf || !rec->rfile_path)
+		return;
+	if (rec->rbuf_offset + size > rec->rbuf_len)
+		sysfs_flush_rbuffer(ctx->callback.private);
+	if (rec->rbuf_offset + size > rec->rbuf_len) {
+		pr_warn("%s: flush failed, or wrong size given(%u, %d)\n",
+				__func__, rec->rbuf_offset, size);
+		return;
+	}
+
+	memcpy(&rec->rbuf[rec->rbuf_offset], data, size);
+	rec->rbuf_offset += size;
+}
+
+static unsigned int nr_damon_targets(struct damon_ctx *ctx)
+{
+	struct damon_target *t;
+	unsigned int nr_targets = 0;
+	int count = 0;
+
+	damon_for_each_target(t, ctx) {
+		count++;
+		nr_targets++;
+	}
+
+	return nr_targets;
+}
+
+/*
+ * Store the aggregated monitoring results to the result buffer
+ *
+ * The format for the result buffer is as below:
+ *
+ *   <time> <number of targets>
+ *
+ *   target info: <pid> <number of regions>
+ *   region info: <start address> <region size> <nr_accesses>
+ */
+static int damon_flush_aggregation(struct damon_ctx *c)
+{
+	struct damon_target *t;
+	struct timespec64 now;
+	struct task_struct *tsk;
+	int tsk_pid = -1;
+	unsigned int nr = 0;
+	char buf[128];
+	int rc = 0;
+
+	memset(buf, 0, sizeof(buf));
+	ktime_get_coarse_ts64(&now);
+	nr = nr_damon_targets(c);
+	rc = scnprintf(buf, sizeof(buf), "time: %lld.%09ld, nr: %u\n",
+			(long long)now.tv_sec, now.tv_nsec, nr);
+	if (!rc)
+		return -ENOMEM;
+
+	sysfs_write_rbuf(c, buf, rc);
+	memset(buf, 0, sizeof(buf));
+
+	damon_for_each_target(t, c) {
+		struct damon_region *r;
+
+		tsk = get_pid_task(t->pid, PIDTYPE_PID);
+		tsk_pid = tsk->pid;
+		nr = damon_nr_regions(t);
+		rc = scnprintf(buf, sizeof(buf), "pid: %d, nr: %u\n", tsk_pid, nr);
+		if (!rc)
+			return -ENOMEM;
+
+		sysfs_write_rbuf(c, buf, rc);
+		memset(buf, 0, sizeof(buf));
+
+		damon_for_each_region(r, t) {
+
+			rc = scnprintf(buf, sizeof(buf), "%lu, %lu, %d\n",
+					r->ar.start, r->ar.end - r->ar.start, r->nr_accesses);
+			if (!rc)
+				return -ENOMEM;
+
+			sysfs_write_rbuf(c, buf, rc);
+			memset(buf, 0, sizeof(buf));
+		}
+	}
+
+	return 0;
+}
+
+/*
+ * damon_sysfs_record() - Save the monitoring results to file.
+ * @kdamond:	The kobject wrapper for the associated kdamond.
+ *
+ * If the sysfs input is wrong, the kdamond will be terminated.
+ */
+static int damon_sysfs_record(struct damon_sysfs_kdamond *kdamond)
+{
+	struct damon_ctx *ctx = kdamond->damon_ctx;
+	struct sysfs_recorder *rec = ctx->callback.private;
+	int err = 0;
+
+	if (!damon_sysfs_kdamond_running(kdamond))
+		return -EINVAL;
+	/* TODO: Support multiple contexts per kdamond */
+	if (kdamond->contexts->nr != 1)
+		return -EINVAL;
+
+	err = damon_flush_aggregation(ctx);
+	if (!err) {
+		if (rec->rbuf_offset)
+			err = sysfs_flush_rbuffer(rec);
+	}
+
+	return err;
+}
+
 /*
  * damon_sysfs_cmd_request_callback() - DAMON callback for handling requests.
  * @c:		The DAMON context of the callback.
@@ -1371,6 +1528,9 @@ static int damon_sysfs_cmd_request_callback(struct damon_ctx *c, bool active)
 	if (!kdamond || kdamond->damon_ctx != c)
 		goto out;
 	switch (damon_sysfs_cmd_request.cmd) {
+	case DAMON_SYSFS_CMD_RECORD:
+		err = damon_sysfs_record(kdamond);
+		break;
 	case DAMON_SYSFS_CMD_UPDATE_SCHEMES_STATS:
 		err = damon_sysfs_upd_schemes_stats(kdamond);
 		break;
@@ -1433,6 +1593,65 @@ static int damon_sysfs_after_aggregation(struct damon_ctx *c)
 	return damon_sysfs_cmd_request_callback(c, true);
 }
 
+/*
+ * sysfs_set_recording() - Set attributes for the recording.
+ * @ctx:	target kdamond context
+ * @rbuf_len:	length of the result buffer
+ * @rfile_path:	path to the monitor result files
+ *
+ * Setting 'rbuf_len' 0 disables recording.
+ *
+ * This function should not be called while the kdamond is running.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+static int sysfs_set_recording(struct damon_ctx *ctx,
+			unsigned int rbuf_len, char *rfile_path)
+{
+	struct sysfs_recorder *recorder;
+	size_t rfile_path_len;
+
+	if (rbuf_len && (rbuf_len > MAX_RECORD_BUFFER_LEN ||
+			rbuf_len < MIN_RECORD_BUFFER_LEN)) {
+		pr_err("result buffer size (%u) is out of [%d,%d]\n",
+				rbuf_len, MIN_RECORD_BUFFER_LEN,
+				MAX_RECORD_BUFFER_LEN);
+		return -EINVAL;
+	}
+	rfile_path_len = strnlen(rfile_path, MAX_RFILE_PATH_LEN);
+	if (rfile_path_len >= MAX_RFILE_PATH_LEN) {
+		pr_err("too long (>%d) result file path %s\n",
+				MAX_RFILE_PATH_LEN, rfile_path);
+		return -EINVAL;
+	}
+
+	recorder = ctx->callback.private;
+	if (!recorder) {
+		recorder = kzalloc(sizeof(*recorder), GFP_KERNEL);
+		if (!recorder)
+			return -ENOMEM;
+		ctx->callback.private = recorder;
+	}
+
+	recorder->rbuf_len = rbuf_len;
+	kfree(recorder->rbuf);
+	recorder->rbuf = NULL;
+	kfree(recorder->rfile_path);
+	recorder->rfile_path = NULL;
+
+	if (rbuf_len) {
+		recorder->rbuf = kvmalloc(rbuf_len, GFP_KERNEL);
+		if (!recorder->rbuf)
+			return -ENOMEM;
+	}
+	recorder->rfile_path = kmalloc(rfile_path_len + 1, GFP_KERNEL);
+	if (!recorder->rfile_path)
+		return -ENOMEM;
+	strscpy(recorder->rfile_path, rfile_path, rfile_path_len + 1);
+
+	return 0;
+}
+
 static struct damon_ctx *damon_sysfs_build_ctx(
 		struct damon_sysfs_context *sys_ctx)
 {
@@ -1442,6 +1661,12 @@ static struct damon_ctx *damon_sysfs_build_ctx(
 	if (!ctx)
 		return ERR_PTR(-ENOMEM);
 
+	err = sysfs_set_recording(ctx, 0, "none");
+	if (err) {
+		damon_destroy_ctx(ctx);
+		return ERR_PTR(err);
+	}
+
 	err = damon_sysfs_apply_inputs(ctx, sys_ctx);
 	if (err) {
 		damon_destroy_ctx(ctx);
@@ -1599,6 +1824,59 @@ static ssize_t pid_show(struct kobject *kobj,
 	return sysfs_emit(buf, "%d\n", pid);
 }
 
+static ssize_t record_show(struct kobject *kobj,
+		struct kobj_attribute *attr, char *buf)
+{
+	struct damon_sysfs_kdamond *kdamond = container_of(kobj,
+			struct damon_sysfs_kdamond, kobj);
+	struct damon_ctx *ctx;
+	struct sysfs_recorder *rec;
+	int len = 0;
+
+	if (!mutex_trylock(&damon_sysfs_lock))
+		return -EBUSY;
+	ctx = kdamond->damon_ctx;
+	if (!ctx)
+		goto out;
+	rec = ctx->callback.private;
+	len = sysfs_emit(buf, "%u %s\n", rec->rbuf_len, rec->rfile_path);
+
+out:
+	mutex_unlock(&damon_sysfs_lock);
+	return len;
+}
+
+static ssize_t record_store(struct kobject *kobj,
+		struct kobj_attribute *attr, const char *buf, size_t count)
+{
+	struct damon_sysfs_kdamond *kdamond = container_of(kobj,
+			struct damon_sysfs_kdamond, kobj);
+	struct damon_ctx *ctx;
+	unsigned int rbuf_len;
+	char rfile_path[MAX_RFILE_PATH_LEN];
+	ssize_t ret = count;
+	int err;
+
+	if (sscanf(buf, "%10u %128s", &rbuf_len, rfile_path) != 2) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	if (!mutex_trylock(&damon_sysfs_lock))
+		return -EBUSY;
+	ctx = kdamond->damon_ctx;
+	if (!ctx)
+		goto unlock_out;
+
+	err = sysfs_set_recording(ctx, rbuf_len, rfile_path);
+	if (err)
+		ret = err;
+unlock_out:
+	mutex_unlock(&damon_sysfs_lock);
+out:
+	return ret;
+}
+
 static void damon_sysfs_kdamond_release(struct kobject *kobj)
 {
 	struct damon_sysfs_kdamond *kdamond = container_of(kobj,
@@ -1615,9 +1893,13 @@ static struct kobj_attribute damon_sysfs_kdamond_state_attr =
 static struct kobj_attribute damon_sysfs_kdamond_pid_attr =
 		__ATTR_RO_MODE(pid, 0400);
 
+static struct kobj_attribute damon_sysfs_kdamond_record_attr =
+		__ATTR_RW_MODE(record, 0600);
+
 static struct attribute *damon_sysfs_kdamond_attrs[] = {
 	&damon_sysfs_kdamond_state_attr.attr,
 	&damon_sysfs_kdamond_pid_attr.attr,
+	&damon_sysfs_kdamond_record_attr.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(damon_sysfs_kdamond);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 2/2] mm/damon/core: add sysfs nodes to set last_nr_accesses weight
  2023-11-28  7:34 [PATCH 1/2] mm/damon/sysfs: Implement recording feature cuiyangpei
@ 2023-11-28  7:34 ` cuiyangpei
  2023-11-28 16:11 ` [PATCH 1/2] mm/damon/sysfs: Implement recording feature kernel test robot
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 22+ messages in thread
From: cuiyangpei @ 2023-11-28  7:34 UTC (permalink / raw)
  To: sj, akpm, damon, linux-mm, linux-kernel; +Cc: cuiyangpei

The date access frequency is cleared every time the aggregation
interval is reached. In order to refer to the past time access
frequency, the current access frequency can be calculated by
setting the weight of the last access frequency.

Signed-off-by: cuiyangpei <cuiyangpei@xiaomi.com>
---
 .../ABI/testing/sysfs-kernel-mm-damon         |  6 ++++
 include/linux/damon.h                         |  3 ++
 mm/damon/core.c                               | 29 +++++++++++++++++
 mm/damon/sysfs.c                              | 31 +++++++++++++++++++
 4 files changed, 69 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index 819534dcfb6c..8367e26bf4da 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -74,6 +74,12 @@ Description:	Writing a keyword for a monitoring operations set ('vaddr' for
 		Note that only the operations sets that listed in
 		'avail_operations' file are valid inputs.
 
+What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/last_nr_accesses_weight
+Date:		Nov 2023
+Contact:	Ping Xiong <xiongping1@xiaomi.com>
+Description:	Writing a value to this file sets last_nr_accesses weight
+		of the DAMON context. Reading this file returns the value.
+
 What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us
 Date:		Mar 2022
 Contact:	SeongJae Park <sj@kernel.org>
diff --git a/include/linux/damon.h b/include/linux/damon.h
index 6495513cc6de..71e67a9d0996 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -18,6 +18,8 @@
 #define DAMON_MIN_REGION	PAGE_SIZE
 /* Max priority score for DAMON-based operation schemes */
 #define DAMOS_MAX_SCORE		(99)
+/* set last_nr_accesses weight */
+#define LAST_NR_ACCESSES_WEIGHT	0
 
 #define MIN_RECORD_BUFFER_LEN	1024
 #define MAX_RECORD_BUFFER_LEN	(4 * 1024 * 1024)
@@ -522,6 +524,7 @@ struct damon_attrs {
 	unsigned long ops_update_interval;
 	unsigned long min_nr_regions;
 	unsigned long max_nr_regions;
+	unsigned int last_nr_accesses_weight;
 };
 
 /**
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 630077d95dc6..230afcceea22 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -1142,6 +1142,34 @@ static void kdamond_apply_schemes(struct damon_ctx *c)
 	}
 }
 
+static unsigned int __calculate_nr_accesses(struct damon_ctx *c, struct damon_region *r)
+{
+	unsigned int rem_old, rem_new;
+	unsigned int res;
+	unsigned int weight = c->attrs.last_nr_accesses_weight;
+
+	res = div_u64_rem(r->nr_accesses, 100, &rem_new) * (100 - weight)
+		+ div_u64_rem(r->last_nr_accesses, 100, &rem_old) * weight;
+
+	if (rem_new)
+		res += rem_new * (100 - weight) / 100;
+	if (rem_old)
+		res += rem_old * weight / 100;
+
+	return res;
+}
+
+static void kdamon_update_nr_accesses(struct damon_ctx *c)
+{
+	struct damon_target *t;
+	struct damon_region *r;
+
+	damon_for_each_target(t, c) {
+		damon_for_each_region(r, t)
+			r->nr_accesses = __calculate_nr_accesses(c, r);
+	}
+}
+
 /*
  * Merge two adjacent regions into one region
  */
@@ -1469,6 +1497,7 @@ static int kdamond_fn(void *data)
 			max_nr_accesses = ctx->ops.check_accesses(ctx);
 
 		if (ctx->passed_sample_intervals == next_aggregation_sis) {
+			kdamon_update_nr_accesses(ctx);
 			kdamond_merge_regions(ctx,
 					max_nr_accesses / 10,
 					sz_limit);
diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index 7a7d41e609e3..2946b0e91ad8 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -544,6 +544,7 @@ struct damon_sysfs_attrs {
 	struct kobject kobj;
 	struct damon_sysfs_intervals *intervals;
 	struct damon_sysfs_ul_range *nr_regions_range;
+	unsigned int last_nr_accesses_weight;
 };
 
 static struct damon_sysfs_attrs *damon_sysfs_attrs_alloc(void)
@@ -553,6 +554,7 @@ static struct damon_sysfs_attrs *damon_sysfs_attrs_alloc(void)
 	if (!attrs)
 		return NULL;
 	attrs->kobj = (struct kobject){};
+	attrs->last_nr_accesses_weight = LAST_NR_ACCESSES_WEIGHT;
 	return attrs;
 }
 
@@ -602,12 +604,40 @@ static void damon_sysfs_attrs_rm_dirs(struct damon_sysfs_attrs *attrs)
 	kobject_put(&attrs->intervals->kobj);
 }
 
+static ssize_t last_nr_accesses_weight_show(struct kobject *kobj,
+		struct kobj_attribute *attr, char *buf)
+{
+	struct damon_sysfs_attrs *attrs = container_of(kobj,
+			struct damon_sysfs_attrs, kobj);
+
+	return sysfs_emit(buf, "%u\n", attrs->last_nr_accesses_weight);
+}
+
+static ssize_t last_nr_accesses_weight_store(struct kobject *kobj,
+		struct kobj_attribute *attr, const char *buf, size_t count)
+{
+	struct damon_sysfs_attrs *attrs = container_of(kobj,
+			struct damon_sysfs_attrs, kobj);
+	int err = kstrtoint(buf, 0, &attrs->last_nr_accesses_weight);
+
+	if (err)
+		return -EINVAL;
+	if (attrs->last_nr_accesses_weight > 100)
+		return -EINVAL;
+
+	return count;
+}
+
 static void damon_sysfs_attrs_release(struct kobject *kobj)
 {
 	kfree(container_of(kobj, struct damon_sysfs_attrs, kobj));
 }
 
+static struct kobj_attribute damon_sysfs_attrs_last_nr_accesses_weight_attr =
+		__ATTR_RW_MODE(last_nr_accesses_weight, 0600);
+
 static struct attribute *damon_sysfs_attrs_attrs[] = {
+	&damon_sysfs_attrs_last_nr_accesses_weight_attr.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(damon_sysfs_attrs);
@@ -1083,6 +1113,7 @@ static int damon_sysfs_set_attrs(struct damon_ctx *ctx,
 		.ops_update_interval = sys_intervals->update_us,
 		.min_nr_regions = sys_nr_regions->min,
 		.max_nr_regions = sys_nr_regions->max,
+		.last_nr_accesses_weight = sys_attrs->last_nr_accesses_weight,
 	};
 	return damon_set_attrs(ctx, &attrs);
 }
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-28  7:34 [PATCH 1/2] mm/damon/sysfs: Implement recording feature cuiyangpei
  2023-11-28  7:34 ` [PATCH 2/2] mm/damon/core: add sysfs nodes to set last_nr_accesses weight cuiyangpei
@ 2023-11-28 16:11 ` kernel test robot
  2023-11-28 16:21 ` kernel test robot
  2023-11-28 18:57 ` SeongJae Park
  3 siblings, 0 replies; 22+ messages in thread
From: kernel test robot @ 2023-11-28 16:11 UTC (permalink / raw)
  To: cuiyangpei, sj, akpm, damon, linux-mm, linux-kernel
  Cc: llvm, oe-kbuild-all, cuiyangpei

Hi cuiyangpei,

kernel test robot noticed the following build warnings:

[auto build test WARNING on akpm-mm/mm-everything]

url:    https://github.com/intel-lab-lkp/linux/commits/cuiyangpei/mm-damon-core-add-sysfs-nodes-to-set-last_nr_accesses-weight/20231128-194153
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20231128073440.11894-1-cuiyangpei%40xiaomi.com
patch subject: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
config: i386-buildonly-randconfig-002-20231128 (https://download.01.org/0day-ci/archive/20231129/202311290004.B2GD9Xbd-lkp@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231129/202311290004.B2GD9Xbd-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/202311290004.B2GD9Xbd-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> mm/damon/sysfs.c:1415:6: warning: variable 'count' set but not used [-Wunused-but-set-variable]
           int count = 0;
               ^
   1 warning generated.


vim +/count +1415 mm/damon/sysfs.c

  1410	
  1411	static unsigned int nr_damon_targets(struct damon_ctx *ctx)
  1412	{
  1413		struct damon_target *t;
  1414		unsigned int nr_targets = 0;
> 1415		int count = 0;
  1416	
  1417		damon_for_each_target(t, ctx) {
  1418			count++;
  1419			nr_targets++;
  1420		}
  1421	
  1422		return nr_targets;
  1423	}
  1424	

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-28  7:34 [PATCH 1/2] mm/damon/sysfs: Implement recording feature cuiyangpei
  2023-11-28  7:34 ` [PATCH 2/2] mm/damon/core: add sysfs nodes to set last_nr_accesses weight cuiyangpei
  2023-11-28 16:11 ` [PATCH 1/2] mm/damon/sysfs: Implement recording feature kernel test robot
@ 2023-11-28 16:21 ` kernel test robot
  2023-11-28 18:57 ` SeongJae Park
  3 siblings, 0 replies; 22+ messages in thread
From: kernel test robot @ 2023-11-28 16:21 UTC (permalink / raw)
  To: cuiyangpei, sj, akpm, damon, linux-mm, linux-kernel
  Cc: llvm, oe-kbuild-all, cuiyangpei

Hi cuiyangpei,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]

url:    https://github.com/intel-lab-lkp/linux/commits/cuiyangpei/mm-damon-core-add-sysfs-nodes-to-set-last_nr_accesses-weight/20231128-194153
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20231128073440.11894-1-cuiyangpei%40xiaomi.com
patch subject: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
config: i386-buildonly-randconfig-001-20231128 (https://download.01.org/0day-ci/archive/20231129/202311290021.Jo3VlA8D-lkp@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231129/202311290021.Jo3VlA8D-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/202311290021.Jo3VlA8D-lkp@intel.com/

All errors (new ones prefixed by >>):

   mm/damon/sysfs.c:1415:6: warning: variable 'count' set but not used [-Wunused-but-set-variable]
           int count = 0;
               ^
   In file included from mm/damon/sysfs.c:2139:
>> mm/damon/sysfs-test.h:15:21: error: redefinition of 'nr_damon_targets'
   static unsigned int nr_damon_targets(struct damon_ctx *ctx)
                       ^
   mm/damon/sysfs.c:1411:21: note: previous definition is here
   static unsigned int nr_damon_targets(struct damon_ctx *ctx)
                       ^
   1 warning and 1 error generated.


vim +/nr_damon_targets +15 mm/damon/sysfs-test.h

b8ee5575f763c2 SeongJae Park 2023-10-22  14  
b8ee5575f763c2 SeongJae Park 2023-10-22 @15  static unsigned int nr_damon_targets(struct damon_ctx *ctx)
b8ee5575f763c2 SeongJae Park 2023-10-22  16  {
b8ee5575f763c2 SeongJae Park 2023-10-22  17  	struct damon_target *t;
b8ee5575f763c2 SeongJae Park 2023-10-22  18  	unsigned int nr_targets = 0;
b8ee5575f763c2 SeongJae Park 2023-10-22  19  
b8ee5575f763c2 SeongJae Park 2023-10-22  20  	damon_for_each_target(t, ctx)
b8ee5575f763c2 SeongJae Park 2023-10-22  21  		nr_targets++;
b8ee5575f763c2 SeongJae Park 2023-10-22  22  
b8ee5575f763c2 SeongJae Park 2023-10-22  23  	return nr_targets;
b8ee5575f763c2 SeongJae Park 2023-10-22  24  }
b8ee5575f763c2 SeongJae Park 2023-10-22  25  

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-28  7:34 [PATCH 1/2] mm/damon/sysfs: Implement recording feature cuiyangpei
                   ` (2 preceding siblings ...)
  2023-11-28 16:21 ` kernel test robot
@ 2023-11-28 18:57 ` SeongJae Park
  2023-11-29 13:13   ` cuiyangpei
  3 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2023-11-28 18:57 UTC (permalink / raw)
  To: cuiyangpei; +Cc: sj, akpm, damon, linux-mm, linux-kernel, cuiyangpei

Hi Cuiyanpei,


Thank you for this nice patchset.

On Tue, 28 Nov 2023 15:34:39 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> The user space users can control DAMON and get the monitoring results
> via implements 'recording' feature in 'damon-sysfs'.  The feature
> can be used via 'record' and 'state' file in the '<sysfs>/kernel/mm/
> damon/admin/kdamonds/N/' directory.
> 
> The file allows users to record monitored access patterns in a text
> file. Firstly, users set the size of the buffer and the path of the
> result file by writing to the ``record`` file. Then the recorded
> results are first written in an in-memory buffer and flushed the
> recorded results to a file in batch by writing 'record' to the
> ``state`` file.
> 
> For example, below commands set the buffer to be 4 KiB and the result
> to be saved in ``/damon.txt``. ::
> 
>     # cd <sysfs>/kernel/mm/damon/admin/kdamonds/N
>     # echo "4096 /damon.txt" > record
>     # echo "record" > state

This reminds me the record feature of DAMON debugfs interface[1], which still
not merged in the mainline.  I deprioritized the patchset to have a better
answer to Andrew's questions on the discussion (nice definition of the binary
format and quatization of the benefit), and later I realized I don't have real
use case that this makes real benefit, so I'm no more aiming to make this
merged into the mainline.

More specifically, I'm now thinking the feature is not really needed since
trace event based recording works, and we found no problem so far.  The DAMON
user-space tool (damo)[2] also dropped support of the in-kernel record feature,
but we received no problem report.

Also, I believe DAMOS tried regions like feature could provide some level of
information, since it provides snapshot of the monitoring result, which
contains a time data, namely 'age'.

Could you please further elaborate your aimed use case of this feature and the
advantage compared to other alternatives (tracepoint-based recording or DAMOS
tried regions based snapshot collecting) I mentioned above?

[1] https://lore.kernel.org/linux-mm/20211011093057.30790-1-sj@kernel.org/
[2] https://github.com/awslabs/damo


Thanks,
SJ

> 
> Signed-off-by: cuiyangpei <cuiyangpei@xiaomi.com>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-28 18:57 ` SeongJae Park
@ 2023-11-29 13:13   ` cuiyangpei
  2023-11-29 17:10     ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2023-11-29 13:13 UTC (permalink / raw)
  To: SeongJae Park, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

Hi SeongJae,

We are using damon on the Android operating system. It starts monitoring
when app comes to the foreground, stops monitoring and save the
monitoring results when app goes to the background.

The two methods that you mentioned,

1.tracepoint events
This method requires opening the tracepoint event and using the
'perf-record' tool to generate the perf.data file. Then parsing the
perf.data file. However, the user's phone is not enabled tracepoint
events. Additionally, the generated file is quite complex, and we only
need memory addresses and access frequency informations.

2. damos
There is no direct Python runtime environment on android phones.

Both of these methods provide results that are not very intuitive and
require complex parsing. We save the results in the format of starting
address, region size, and access frequency. When the available memory
reaches a threshold, the user space reclaim memory with low access
frequency by calling 'process_madvise' function.

Thanks.

On Tue, Nov 28, 2023 at 06:57:39PM +0000, SeongJae Park wrote:
> Hi Cuiyanpei,
> 
> 
> Thank you for this nice patchset.
> 
> On Tue, 28 Nov 2023 15:34:39 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > The user space users can control DAMON and get the monitoring results
> > via implements 'recording' feature in 'damon-sysfs'.  The feature
> > can be used via 'record' and 'state' file in the '<sysfs>/kernel/mm/
> > damon/admin/kdamonds/N/' directory.
> > 
> > The file allows users to record monitored access patterns in a text
> > file. Firstly, users set the size of the buffer and the path of the
> > result file by writing to the ``record`` file. Then the recorded
> > results are first written in an in-memory buffer and flushed the
> > recorded results to a file in batch by writing 'record' to the
> > ``state`` file.
> > 
> > For example, below commands set the buffer to be 4 KiB and the result
> > to be saved in ``/damon.txt``. ::
> > 
> >     # cd <sysfs>/kernel/mm/damon/admin/kdamonds/N
> >     # echo "4096 /damon.txt" > record
> >     # echo "record" > state
> 
> This reminds me the record feature of DAMON debugfs interface[1], which still
> not merged in the mainline.  I deprioritized the patchset to have a better
> answer to Andrew's questions on the discussion (nice definition of the binary
> format and quatization of the benefit), and later I realized I don't have real
> use case that this makes real benefit, so I'm no more aiming to make this
> merged into the mainline.
> 
> More specifically, I'm now thinking the feature is not really needed since
> trace event based recording works, and we found no problem so far.  The DAMON
> user-space tool (damo)[2] also dropped support of the in-kernel record feature,
> but we received no problem report.
> 
> Also, I believe DAMOS tried regions like feature could provide some level of
> information, since it provides snapshot of the monitoring result, which
> contains a time data, namely 'age'.
> 
> Could you please further elaborate your aimed use case of this feature and the
> advantage compared to other alternatives (tracepoint-based recording or DAMOS
> tried regions based snapshot collecting) I mentioned above?
> 
> [1] https://lore.kernel.org/linux-mm/20211011093057.30790-1-sj@kernel.org/
> [2] https://github.com/awslabs/damo
> 
> 
> Thanks,
> SJ
> 
> > 
> > Signed-off-by: cuiyangpei <cuiyangpei@xiaomi.com>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-29 13:13   ` cuiyangpei
@ 2023-11-29 17:10     ` SeongJae Park
  2023-11-30  9:14       ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2023-11-29 17:10 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

Hi Cuiyangpei,

On Wed, 29 Nov 2023 21:13:15 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> Hi SeongJae,
> 
> We are using damon on the Android operating system. It starts monitoring
> when app comes to the foreground, stops monitoring and save the
> monitoring results when app goes to the background.

Thank you so much for sharing this detailed use case.  This will be very
helpful for us at understanding real usage of DAMON and making it better for
that together.

> 
> The two methods that you mentioned,
> 
> 1.tracepoint events
> This method requires opening the tracepoint event and using the
> 'perf-record' tool to generate the perf.data file. Then parsing the
> perf.data file. However, the user's phone is not enabled tracepoint
> events. Additionally, the generated file is quite complex, and we only
> need memory addresses and access frequency informations.

That's fair points, thank you for kindly explaining this.

> 
> 2. damos
> There is no direct Python runtime environment on android phones.
> 
> Both of these methods provide results that are not very intuitive and
> require complex parsing. We save the results in the format of starting
> address, region size, and access frequency. When the available memory
> reaches a threshold, the user space reclaim memory with low access
> frequency by calling 'process_madvise' function.

Again, very fair points.  So, if I understood correctly, you want to reclaim
cold pages proactively when the available memory reaches a threshold, right?
DAMON could do that directly instead of you[1].  Using that, you don't need to
save the access pattern and parse but just ask DAMON to find memory regions of
specific access frequency range and reclaim.  Have you also considered using
that but found some problems?

I understand the feature may not perfectly fit for your use case, and I want to
learn from you how it could be better.

[1] https://docs.kernel.org/mm/damon/design.html#operation-schemes


Thanks,
SJ

> 
> Thanks.
> 
[...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-29 17:10     ` SeongJae Park
@ 2023-11-30  9:14       ` cuiyangpei
  2023-11-30 19:44         ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2023-11-30  9:14 UTC (permalink / raw)
  To: SeongJae Park, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

Hi SeongJae,

We also investigated the operation schemes you mentioned, but we don't
think it can fit our needs.

On android, user will open many apps and switch between these apps as
needs. We hope to monitor apps' memory access only when they are on
foreground and record the memory access pattern when they are switched
to the background. 

When avaliable memory reaches a threshold, we will use these access
patterns with some strategies to recognize those memory that will have
little impact on user experience and to reclaim them proactively.  

I'm not sure I have clarified it clearly, if you still have questions
on this, please let us know.

Thanks.

On Wed, Nov 29, 2023 at 05:10:58PM +0000, SeongJae Park wrote:
> Hi Cuiyangpei,
> 
> On Wed, 29 Nov 2023 21:13:15 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > Hi SeongJae,
> > 
> > We are using damon on the Android operating system. It starts monitoring
> > when app comes to the foreground, stops monitoring and save the
> > monitoring results when app goes to the background.
> 
> Thank you so much for sharing this detailed use case.  This will be very
> helpful for us at understanding real usage of DAMON and making it better for
> that together.
> 
> > 
> > The two methods that you mentioned,
> > 
> > 1.tracepoint events
> > This method requires opening the tracepoint event and using the
> > 'perf-record' tool to generate the perf.data file. Then parsing the
> > perf.data file. However, the user's phone is not enabled tracepoint
> > events. Additionally, the generated file is quite complex, and we only
> > need memory addresses and access frequency informations.
> 
> That's fair points, thank you for kindly explaining this.
> 
> > 
> > 2. damos
> > There is no direct Python runtime environment on android phones.
> > 
> > Both of these methods provide results that are not very intuitive and
> > require complex parsing. We save the results in the format of starting
> > address, region size, and access frequency. When the available memory
> > reaches a threshold, the user space reclaim memory with low access
> > frequency by calling 'process_madvise' function.
> 
> Again, very fair points.  So, if I understood correctly, you want to reclaim
> cold pages proactively when the available memory reaches a threshold, right?
> DAMON could do that directly instead of you[1].  Using that, you don't need to
> save the access pattern and parse but just ask DAMON to find memory regions of
> specific access frequency range and reclaim.  Have you also considered using
> that but found some problems?
> 
> I understand the feature may not perfectly fit for your use case, and I want to
> learn from you how it could be better.
> 
> [1] https://docs.kernel.org/mm/damon/design.html#operation-schemes
> 
> 
> Thanks,
> SJ
> 
> > 
> > Thanks.
> > 
> [...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-30  9:14       ` cuiyangpei
@ 2023-11-30 19:44         ` SeongJae Park
  2023-12-01 12:25           ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2023-11-30 19:44 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

Hi Cuiyangpei,

On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> Hi SeongJae,
> 
> We also investigated the operation schemes you mentioned, but we don't
> think it can fit our needs.
> 
> On android, user will open many apps and switch between these apps as
> needs. We hope to monitor apps' memory access only when they are on
> foreground and record the memory access pattern when they are switched
> to the background. 
> 
> When avaliable memory reaches a threshold, we will use these access
> patterns with some strategies to recognize those memory that will have
> little impact on user experience and to reclaim them proactively.  
> 
> I'm not sure I have clarified it clearly, if you still have questions
> on this, please let us know.

So, to my understanding, you expect applications may keep similar access
pattern when they are in foreground, but have a different, less aggressive
access pattern in background, and therefore reclaim memory based on the
foreground-access pattern, right?

Very interesting idea, thank you for sharing!

Then, yes, I agree current DAMOS might not that helpful for the situation, and
this record feature could be useful for your case.

That said, do you really need full recording of the monitoring results?  If
not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
monitoring results snapshot that include both frequency and recency of all
regions in an efficient way.  If single snapshot is not having enough
information for you, you could collect multiple snapshots.

You mentioned absence of Python on Android as a blocker of DAMOS use on the
previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
or Python.

Of course, I think you might already surveyed it but found some problems.
Could you please share that in detail if so?

[1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions 
[2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/


Thanks,
SJ

> 
> Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-11-30 19:44         ` SeongJae Park
@ 2023-12-01 12:25           ` cuiyangpei
  2023-12-01 17:31             ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2023-12-01 12:25 UTC (permalink / raw)
  To: SeongJae Park, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> Hi Cuiyangpei,
> 
> On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > Hi SeongJae,
> > 
> > We also investigated the operation schemes you mentioned, but we don't
> > think it can fit our needs.
> > 
> > On android, user will open many apps and switch between these apps as
> > needs. We hope to monitor apps' memory access only when they are on
> > foreground and record the memory access pattern when they are switched
> > to the background. 
> > 
> > When avaliable memory reaches a threshold, we will use these access
> > patterns with some strategies to recognize those memory that will have
> > little impact on user experience and to reclaim them proactively.  
> > 
> > I'm not sure I have clarified it clearly, if you still have questions
> > on this, please let us know.
> 
> So, to my understanding, you expect applications may keep similar access
> pattern when they are in foreground, but have a different, less aggressive
> access pattern in background, and therefore reclaim memory based on the
> foreground-access pattern, right?
>

Different apps may have different access pattern. On android, the apps will
join in freeze cgroup and be frozen after switch to the background. So we 
monitor apps' memory access only when they are in foreground.
> Very interesting idea, thank you for sharing!
> 
> Then, yes, I agree current DAMOS might not that helpful for the situation, and
> this record feature could be useful for your case.
> 
> That said, do you really need full recording of the monitoring results?  If
> not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
> monitoring results snapshot that include both frequency and recency of all
> regions in an efficient way.  If single snapshot is not having enough
> information for you, you could collect multiple snapshots.
> 
> You mentioned absence of Python on Android as a blocker of DAMOS use on the
> previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
> or Python.
> 
> Of course, I think you might already surveyed it but found some problems.
> Could you please share that in detail if so?
> 
DAMOS tried regions feature you mentioned is not fully applicable. It needs to
apply schemes on regions. There is no available scheme we can use for our use
case. What we need is to return regions with access frequency and recency to
userspace for later use.
> [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions 
> [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/
> 
> 
> Thanks,
> SJ
> 
> > 
> > Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-12-01 12:25           ` cuiyangpei
@ 2023-12-01 17:31             ` SeongJae Park
  2023-12-03  5:43               ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2023-12-01 17:31 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

Hi Cuiyangpei,

On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > Hi Cuiyangpei,
> > 
> > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > 
> > > Hi SeongJae,
> > > 
> > > We also investigated the operation schemes you mentioned, but we don't
> > > think it can fit our needs.
> > > 
> > > On android, user will open many apps and switch between these apps as
> > > needs. We hope to monitor apps' memory access only when they are on
> > > foreground and record the memory access pattern when they are switched
> > > to the background. 
> > > 
> > > When avaliable memory reaches a threshold, we will use these access
> > > patterns with some strategies to recognize those memory that will have
> > > little impact on user experience and to reclaim them proactively.  
> > > 
> > > I'm not sure I have clarified it clearly, if you still have questions
> > > on this, please let us know.
> > 
> > So, to my understanding, you expect applications may keep similar access
> > pattern when they are in foreground, but have a different, less aggressive
> > access pattern in background, and therefore reclaim memory based on the
> > foreground-access pattern, right?
> >
> 
> Different apps may have different access pattern. On android, the apps will
> join in freeze cgroup and be frozen after switch to the background. So we 
> monitor apps' memory access only when they are in foreground.

Thank you for this enlightening me :)

> > Very interesting idea, thank you for sharing!
> > 
> > Then, yes, I agree current DAMOS might not that helpful for the situation, and
> > this record feature could be useful for your case.
> > 
> > That said, do you really need full recording of the monitoring results?  If
> > not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
> > monitoring results snapshot that include both frequency and recency of all
> > regions in an efficient way.  If single snapshot is not having enough
> > information for you, you could collect multiple snapshots.
> > 
> > You mentioned absence of Python on Android as a blocker of DAMOS use on the
> > previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
> > or Python.
> > 
> > Of course, I think you might already surveyed it but found some problems.
> > Could you please share that in detail if so?
> > 
> DAMOS tried regions feature you mentioned is not fully applicable. It needs to
> apply schemes on regions. There is no available scheme we can use for our use
> case. What we need is to return regions with access frequency and recency to
> userspace for later use.


Thank you for the answer, I understand your concern.  One of the available
DAMOS action is 'stat'[1], which does nothing but just count the statistic.
Using DAMOS scheme for any access pattern with 'stat' action, you can extract
the access pattern via DAMOS tried regions feature of DAMON sysfs interface,
without making any unnecessary impact to the workload.

Quote from [2]:

    The expected usage of this directory is investigations of schemes' behaviors,
    and query-like efficient data access monitoring results retrievals. For the
    latter use case, in particular, users can set the action as stat and set the
    access pattern as their interested pattern that they want to query.

For example, you could

# cd /sys/kernel/mm/damon/admin
#
# # populate directories
# echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts;
# echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
# cd kdamonds/0/contexts/0/schemes/0
#
# # set the access pattern for any case (max as 2**64 - 1), and action as stat
# echo 0 > access_pattern/sz/min
# echo 18446744073709551615 > access_pattern/sz/max
# echo 0 > access_pattern/nr_accesses/min
# echo 18446744073709551615 > access_pattern/nr_accesses/max
# echo 0 > access_pattern/age/min
# echo 18446744073709551615 > access_pattern/age/max
# echo stat > action

And this is how DAMON user-space tool is getting the snapshot with 'damo show'
command[3].

Could this be used for your case?  Please ask any question if you have :)

[1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n
[2] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions,
[3] https://github.com/awslabs/damo/blob/next/USAGE.md#damo-show


Thanks,
SJ

> > [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions 
> > [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/
> > 
> > 
> > Thanks,
> > SJ
> > 
> > > 
> > > Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-12-01 17:31             ` SeongJae Park
@ 2023-12-03  5:43               ` cuiyangpei
  2023-12-03 19:37                 ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2023-12-03  5:43 UTC (permalink / raw)
  To: SeongJae Park, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> Hi Cuiyangpei,
> 
> On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > Hi Cuiyangpei,
> > > 
> > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > 
> > > > Hi SeongJae,
> > > > 
> > > > We also investigated the operation schemes you mentioned, but we don't
> > > > think it can fit our needs.
> > > > 
> > > > On android, user will open many apps and switch between these apps as
> > > > needs. We hope to monitor apps' memory access only when they are on
> > > > foreground and record the memory access pattern when they are switched
> > > > to the background. 
> > > > 
> > > > When avaliable memory reaches a threshold, we will use these access
> > > > patterns with some strategies to recognize those memory that will have
> > > > little impact on user experience and to reclaim them proactively.  
> > > > 
> > > > I'm not sure I have clarified it clearly, if you still have questions
> > > > on this, please let us know.
> > > 
> > > So, to my understanding, you expect applications may keep similar access
> > > pattern when they are in foreground, but have a different, less aggressive
> > > access pattern in background, and therefore reclaim memory based on the
> > > foreground-access pattern, right?
> > >
> > 
> > Different apps may have different access pattern. On android, the apps will
> > join in freeze cgroup and be frozen after switch to the background. So we 
> > monitor apps' memory access only when they are in foreground.
> 
> Thank you for this enlightening me :)
> 
> > > Very interesting idea, thank you for sharing!
> > > 
> > > Then, yes, I agree current DAMOS might not that helpful for the situation, and
> > > this record feature could be useful for your case.
> > > 
> > > That said, do you really need full recording of the monitoring results?  If
> > > not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
> > > monitoring results snapshot that include both frequency and recency of all
> > > regions in an efficient way.  If single snapshot is not having enough
> > > information for you, you could collect multiple snapshots.
> > > 
> > > You mentioned absence of Python on Android as a blocker of DAMOS use on the
> > > previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
> > > or Python.
> > > 
> > > Of course, I think you might already surveyed it but found some problems.
> > > Could you please share that in detail if so?
> > > 
> > DAMOS tried regions feature you mentioned is not fully applicable. It needs to
> > apply schemes on regions. There is no available scheme we can use for our use
> > case. What we need is to return regions with access frequency and recency to
> > userspace for later use.
> 
> 
> Thank you for the answer, I understand your concern.  One of the available
> DAMOS action is 'stat'[1], which does nothing but just count the statistic.
> Using DAMOS scheme for any access pattern with 'stat' action, you can extract
> the access pattern via DAMOS tried regions feature of DAMON sysfs interface,
> without making any unnecessary impact to the workload.
> 
> Quote from [2]:
> 
>     The expected usage of this directory is investigations of schemes' behaviors,
>     and query-like efficient data access monitoring results retrievals. For the
>     latter use case, in particular, users can set the action as stat and set the
>     access pattern as their interested pattern that they want to query.
> 
> For example, you could
> 
> # cd /sys/kernel/mm/damon/admin
> #
> # # populate directories
> # echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts;
> # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
> # cd kdamonds/0/contexts/0/schemes/0
> #
> # # set the access pattern for any case (max as 2**64 - 1), and action as stat
> # echo 0 > access_pattern/sz/min
> # echo 18446744073709551615 > access_pattern/sz/max
> # echo 0 > access_pattern/nr_accesses/min
> # echo 18446744073709551615 > access_pattern/nr_accesses/max
> # echo 0 > access_pattern/age/min
> # echo 18446744073709551615 > access_pattern/age/max
> # echo stat > action
> 
> And this is how DAMON user-space tool is getting the snapshot with 'damo show'
> command[3].
> 
> Could this be used for your case?  Please ask any question if you have :)
> 
> [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n
> [2] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions,
> [3] https://github.com/awslabs/damo/blob/next/USAGE.md#damo-show

Thank you for your detailed response, it is very helpful to us. We will look into it
and contact you if we have any questions.

> 
> 
> Thanks,
> SJ
> 
> > > [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions 
> > > [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/
> > > 
> > > 
> > > Thanks,
> > > SJ
> > > 
> > > > 
> > > > Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-12-03  5:43               ` cuiyangpei
@ 2023-12-03 19:37                 ` SeongJae Park
  2024-01-22  5:46                   ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2023-12-03 19:37 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:

> On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > Hi Cuiyangpei,
> > 
> > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > 
> > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > > Hi Cuiyangpei,
> > > > 
> > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > 
> > > > > Hi SeongJae,
> > > > > 
> > > > > We also investigated the operation schemes you mentioned, but we don't
> > > > > think it can fit our needs.
> > > > > 
> > > > > On android, user will open many apps and switch between these apps as
> > > > > needs. We hope to monitor apps' memory access only when they are on
> > > > > foreground and record the memory access pattern when they are switched
> > > > > to the background. 
> > > > > 
> > > > > When avaliable memory reaches a threshold, we will use these access
> > > > > patterns with some strategies to recognize those memory that will have
> > > > > little impact on user experience and to reclaim them proactively.  
> > > > > 
> > > > > I'm not sure I have clarified it clearly, if you still have questions
> > > > > on this, please let us know.
> > > > 
> > > > So, to my understanding, you expect applications may keep similar access
> > > > pattern when they are in foreground, but have a different, less aggressive
> > > > access pattern in background, and therefore reclaim memory based on the
> > > > foreground-access pattern, right?
> > > >
> > > 
> > > Different apps may have different access pattern. On android, the apps will
> > > join in freeze cgroup and be frozen after switch to the background. So we 
> > > monitor apps' memory access only when they are in foreground.
> > 
> > Thank you for this enlightening me :)
> > 
> > > > Very interesting idea, thank you for sharing!
> > > > 
> > > > Then, yes, I agree current DAMOS might not that helpful for the situation, and
> > > > this record feature could be useful for your case.
> > > > 
> > > > That said, do you really need full recording of the monitoring results?  If
> > > > not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
> > > > monitoring results snapshot that include both frequency and recency of all
> > > > regions in an efficient way.  If single snapshot is not having enough
> > > > information for you, you could collect multiple snapshots.
> > > > 
> > > > You mentioned absence of Python on Android as a blocker of DAMOS use on the
> > > > previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
> > > > or Python.
> > > > 
> > > > Of course, I think you might already surveyed it but found some problems.
> > > > Could you please share that in detail if so?
> > > > 
> > > DAMOS tried regions feature you mentioned is not fully applicable. It needs to
> > > apply schemes on regions. There is no available scheme we can use for our use
> > > case. What we need is to return regions with access frequency and recency to
> > > userspace for later use.
> > 
> > 
> > Thank you for the answer, I understand your concern.  One of the available
> > DAMOS action is 'stat'[1], which does nothing but just count the statistic.
> > Using DAMOS scheme for any access pattern with 'stat' action, you can extract
> > the access pattern via DAMOS tried regions feature of DAMON sysfs interface,
> > without making any unnecessary impact to the workload.
> > 
> > Quote from [2]:
> > 
> >     The expected usage of this directory is investigations of schemes' behaviors,
> >     and query-like efficient data access monitoring results retrievals. For the
> >     latter use case, in particular, users can set the action as stat and set the
> >     access pattern as their interested pattern that they want to query.
> > 
> > For example, you could
> > 
> > # cd /sys/kernel/mm/damon/admin
> > #
> > # # populate directories
> > # echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts;
> > # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
> > # cd kdamonds/0/contexts/0/schemes/0
> > #
> > # # set the access pattern for any case (max as 2**64 - 1), and action as stat
> > # echo 0 > access_pattern/sz/min
> > # echo 18446744073709551615 > access_pattern/sz/max
> > # echo 0 > access_pattern/nr_accesses/min
> > # echo 18446744073709551615 > access_pattern/nr_accesses/max
> > # echo 0 > access_pattern/age/min
> > # echo 18446744073709551615 > access_pattern/age/max
> > # echo stat > action
> > 
> > And this is how DAMON user-space tool is getting the snapshot with 'damo show'
> > command[3].
> > 
> > Could this be used for your case?  Please ask any question if you have :)
> > 
> > [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n
> > [2] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions,
> > [3] https://github.com/awslabs/damo/blob/next/USAGE.md#damo-show
> 
> Thank you for your detailed response, it is very helpful to us. We will look into it
> and contact you if we have any questions.

So glad to hear this.  Please let me know if you have any questions or need any
help :)


Thanks,
SJ

> 
> > 
> > 
> > Thanks,
> > SJ
> > 
> > > > [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions 
> > > > [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/
> > > > 
> > > > 
> > > > Thanks,
> > > > SJ
> > > > 
> > > > > 
> > > > > Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2023-12-03 19:37                 ` SeongJae Park
@ 2024-01-22  5:46                   ` cuiyangpei
  2024-01-22 17:56                     ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2024-01-22  5:46 UTC (permalink / raw)
  To: SeongJae Park, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote:
> On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > > Hi Cuiyangpei,
> > > 
> > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > 
> > > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > > > Hi Cuiyangpei,
> > > > > 
> > > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > > 
> > > > > > Hi SeongJae,
> > > > > > 
> > > > > > We also investigated the operation schemes you mentioned, but we don't
> > > > > > think it can fit our needs.
> > > > > > 
> > > > > > On android, user will open many apps and switch between these apps as
> > > > > > needs. We hope to monitor apps' memory access only when they are on
> > > > > > foreground and record the memory access pattern when they are switched
> > > > > > to the background. 
> > > > > > 
> > > > > > When avaliable memory reaches a threshold, we will use these access
> > > > > > patterns with some strategies to recognize those memory that will have
> > > > > > little impact on user experience and to reclaim them proactively.  
> > > > > > 
> > > > > > I'm not sure I have clarified it clearly, if you still have questions
> > > > > > on this, please let us know.
> > > > > 
> > > > > So, to my understanding, you expect applications may keep similar access
> > > > > pattern when they are in foreground, but have a different, less aggressive
> > > > > access pattern in background, and therefore reclaim memory based on the
> > > > > foreground-access pattern, right?
> > > > >
> > > > 
> > > > Different apps may have different access pattern. On android, the apps will
> > > > join in freeze cgroup and be frozen after switch to the background. So we 
> > > > monitor apps' memory access only when they are in foreground.
> > > 
> > > Thank you for this enlightening me :)
> > > 
> > > > > Very interesting idea, thank you for sharing!
> > > > > 
> > > > > Then, yes, I agree current DAMOS might not that helpful for the situation, and
> > > > > this record feature could be useful for your case.
> > > > > 
> > > > > That said, do you really need full recording of the monitoring results?  If
> > > > > not, DAMOS provides DAMOS tried regions feature[1], which allows users get the
> > > > > monitoring results snapshot that include both frequency and recency of all
> > > > > regions in an efficient way.  If single snapshot is not having enough
> > > > > information for you, you could collect multiple snapshots.
> > > > > 
> > > > > You mentioned absence of Python on Android as a blocker of DAMOS use on the
> > > > > previous reply[2], but DAMOS tried regions feature is not depend on tracepoints
> > > > > or Python.
> > > > > 
> > > > > Of course, I think you might already surveyed it but found some problems.
> > > > > Could you please share that in detail if so?
> > > > > 
> > > > DAMOS tried regions feature you mentioned is not fully applicable. It needs to
> > > > apply schemes on regions. There is no available scheme we can use for our use
> > > > case. What we need is to return regions with access frequency and recency to
> > > > userspace for later use.
> > > 
> > > 
> > > Thank you for the answer, I understand your concern.  One of the available
> > > DAMOS action is 'stat'[1], which does nothing but just count the statistic.
> > > Using DAMOS scheme for any access pattern with 'stat' action, you can extract
> > > the access pattern via DAMOS tried regions feature of DAMON sysfs interface,
> > > without making any unnecessary impact to the workload.
> > > 
> > > Quote from [2]:
> > > 
> > >     The expected usage of this directory is investigations of schemes' behaviors,
> > >     and query-like efficient data access monitoring results retrievals. For the
> > >     latter use case, in particular, users can set the action as stat and set the
> > >     access pattern as their interested pattern that they want to query.
> > > 
> > > For example, you could
> > > 
> > > # cd /sys/kernel/mm/damon/admin
> > > #
> > > # # populate directories
> > > # echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts;
> > > # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
> > > # cd kdamonds/0/contexts/0/schemes/0
> > > #
> > > # # set the access pattern for any case (max as 2**64 - 1), and action as stat
> > > # echo 0 > access_pattern/sz/min
> > > # echo 18446744073709551615 > access_pattern/sz/max
> > > # echo 0 > access_pattern/nr_accesses/min
> > > # echo 18446744073709551615 > access_pattern/nr_accesses/max
> > > # echo 0 > access_pattern/age/min
> > > # echo 18446744073709551615 > access_pattern/age/max
> > > # echo stat > action
> > > 
> > > And this is how DAMON user-space tool is getting the snapshot with 'damo show'
> > > command[3].
> > > 
> > > Could this be used for your case?  Please ask any question if you have :)
> > > 
> > > [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n
> > > [2] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions,
> > > [3] https://github.com/awslabs/damo/blob/next/USAGE.md#damo-show
> > 
> > Thank you for your detailed response, it is very helpful to us. We will look into it
> > and contact you if we have any questions.
> 
> So glad to hear this.  Please let me know if you have any questions or need any
> help :)
> 
> 
> Thanks,
> SJ
> 
> > 
> > > 
> > > 
> > > Thanks,
> > > SJ
> > > 
> > > > > [1] https://docs.kernel.org/admin-guide/mm/damon/usage.html#schemes-n-tried-regions 
> > > > > [2] https://lore.kernel.org/damon/20231129131315.GB12957@cuiyangpei/
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > SJ
> > > > > 
> > > > > > 
> > > > > > Thanks.

Hi SeongJae,

We set 'access_pattern' and 'stat' action in schemes when apps are on
foreground, record apps' memory access pattern when they are switched
to the background with 'update_schemes_tried_regions' state. But it
catch the snapshot after next aggregation interval. DAMON is still
sampling during the app switches to the background and the next
aggregation time, which can cause the value of "age" to change. The
sampling results during this period cannot accurately reflect the app's
foreground access pattern.

Is there any way to catch sampling result immediately after setting the
"update_schemes_tried_regions" state? Alternatively, can it return the
"last_nr_accesses" and "last_age" values in tried_regions/<N> directory?

Do you have any other suggestions?

Thanks.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-22  5:46                   ` cuiyangpei
@ 2024-01-22 17:56                     ` SeongJae Park
  2024-01-26  6:57                       ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2024-01-22 17:56 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

Hi cuiyangpei,

On Mon, 22 Jan 2024 13:46:31 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote:
> > On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > 
> > > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > > > Hi Cuiyangpei,
> > > > 
> > > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > 
> > > > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > > > > Hi Cuiyangpei,
> > > > > > 
> > > > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
[...]
> 
> Hi SeongJae,
> 
> We set 'access_pattern' and 'stat' action in schemes when apps are on
> foreground, record apps' memory access pattern when they are switched
> to the background with 'update_schemes_tried_regions' state. But it
> catch the snapshot after next aggregation interval. DAMON is still
> sampling during the app switches to the background and the next
> aggregation time, which can cause the value of "age" to change. The
> sampling results during this period cannot accurately reflect the app's
> foreground access pattern.
> 
> Is there any way to catch sampling result immediately after setting the
> "update_schemes_tried_regions" state?

There is no way for exactly doing this.  You would need to proactively collect
snapshots while the app is foreground, and use the latest one that collected
before the app goes background, like recording-based approach would do.

I think recent DAMON changes might make an alternative approach available,
though.  From v6.7, DAMON provides pseudo-moving-average monitoring result in
sampling interval granualrity, since patchset "mm/damon: provide pseudo-moving
sum based access rate".  And a followup patchset, namely "mm/damon: implement
DAMOS apply intervals", has made DAMOS works in the sampling interval
granualrity.  Both patchsets are merged into v6.7-rc1.

Hence, I think you could use 'update_schemes_tried_regions' after you noticed
the app's state transition, with DAMOS apply interval of one sampling interval.
Then you will get the monitoring results after one sampling interval.  Of
course, the snapshot may contain some of background access pattern, but
wouldn't made it changed significantly, unless you set aggregation interval too
short.

> Alternatively, can it return the "last_nr_accesses" and "last_age" values in
> tried_regions/<N> directory?

This could also be a good alternative in my think.  Nice idea.  But, because
the previously mentioned alternative is already available while this require a
bit small but additional changes, could we check if the previously one make
sense and works first?  We could revisit this idea if it turns out the previous
alternative is not suffice in my opinion.

> 
> Do you have any other suggestions?

As I mentioned above, I'd suggest the DAMOS apply interval of single sampling
interval for now.


Thanks,
SJ

> 
> Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-22 17:56                     ` SeongJae Park
@ 2024-01-26  6:57                       ` cuiyangpei
  2024-01-26  8:04                         ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2024-01-26  6:57 UTC (permalink / raw)
  To: SeongJae Park, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

On Mon, Jan 22, 2024 at 09:56:11AM -0800, SeongJae Park wrote:
> Hi cuiyangpei,
> 
> On Mon, 22 Jan 2024 13:46:31 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote:
> > > On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > 
> > > > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > > > > Hi Cuiyangpei,
> > > > > 
> > > > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > > 
> > > > > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > > > > > Hi Cuiyangpei,
> > > > > > > 
> > > > > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> [...]
> > 
> > Hi SeongJae,
> > 
> > We set 'access_pattern' and 'stat' action in schemes when apps are on
> > foreground, record apps' memory access pattern when they are switched
> > to the background with 'update_schemes_tried_regions' state. But it
> > catch the snapshot after next aggregation interval. DAMON is still
> > sampling during the app switches to the background and the next
> > aggregation time, which can cause the value of "age" to change. The
> > sampling results during this period cannot accurately reflect the app's
> > foreground access pattern.
> > 
> > Is there any way to catch sampling result immediately after setting the
> > "update_schemes_tried_regions" state?
> 
> There is no way for exactly doing this.  You would need to proactively collect
> snapshots while the app is foreground, and use the latest one that collected
> before the app goes background, like recording-based approach would do.
> 
> I think recent DAMON changes might make an alternative approach available,
> though.  From v6.7, DAMON provides pseudo-moving-average monitoring result in
> sampling interval granualrity, since patchset "mm/damon: provide pseudo-moving
> sum based access rate".  And a followup patchset, namely "mm/damon: implement
> DAMOS apply intervals", has made DAMOS works in the sampling interval
> granualrity.  Both patchsets are merged into v6.7-rc1.
> 
> Hence, I think you could use 'update_schemes_tried_regions' after you noticed
> the app's state transition, with DAMOS apply interval of one sampling interval.
> Then you will get the monitoring results after one sampling interval.  Of
> course, the snapshot may contain some of background access pattern, but
> wouldn't made it changed significantly, unless you set aggregation interval too
> short.

All other actions will apply at one sampling interval except for the
`stat` action.

We use 'update_schemes_tried_regions' after switch to the background. The 
before_damos_apply callback function will only be set when the next aggregation
interval arrives. The `tried_regions` will only be updated after setting the 
callback function. 

DAMON is still sampling during setting 'update_schemes_tried_regions' to the next
aggregation time, which is not what we expected. The pseudo-moving-average
monitoring result can reduce nr_accesees inaccuracy, but age is still being modified
during this time, so it can't improve this issue.

Please let me know if my understanding is incorrect. Thank you.
> 
> > Alternatively, can it return the "last_nr_accesses" and "last_age" values in
> > tried_regions/<N> directory?
> 
> This could also be a good alternative in my think.  Nice idea.  But, because
> the previously mentioned alternative is already available while this require a
> bit small but additional changes, could we check if the previously one make
> sense and works first?  We could revisit this idea if it turns out the previous
> alternative is not suffice in my opinion.
> 
Can you consider adding "last_nr_accesses" and "last_age"  two files in
'tried_regions/<N>' directory?

Thanks.
> > 
> > Do you have any other suggestions?
> 
> As I mentioned above, I'd suggest the DAMOS apply interval of single sampling
> interval for now.
> 
> 
> Thanks,
> SJ
> 
> > 
> > Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-26  6:57                       ` cuiyangpei
@ 2024-01-26  8:04                         ` SeongJae Park
  2024-01-28  9:13                           ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2024-01-26  8:04 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

On Fri, 26 Jan 2024 14:57:06 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> On Mon, Jan 22, 2024 at 09:56:11AM -0800, SeongJae Park wrote:
> > Hi cuiyangpei,
> > 
> > On Mon, 22 Jan 2024 13:46:31 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > 
> > > On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote:
> > > > On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > 
> > > > > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > > > > > Hi Cuiyangpei,
> > > > > > 
> > > > > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > > > 
> > > > > > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > > > > > > Hi Cuiyangpei,
> > > > > > > > 
> > > > > > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
[...]
> > > Is there any way to catch sampling result immediately after setting the
> > > "update_schemes_tried_regions" state?
> > 
> > There is no way for exactly doing this.  You would need to proactively collect
> > snapshots while the app is foreground, and use the latest one that collected
> > before the app goes background, like recording-based approach would do.
> > 
> > I think recent DAMON changes might make an alternative approach available,
> > though.  From v6.7, DAMON provides pseudo-moving-average monitoring result in
> > sampling interval granualrity, since patchset "mm/damon: provide pseudo-moving
> > sum based access rate".  And a followup patchset, namely "mm/damon: implement
> > DAMOS apply intervals", has made DAMOS works in the sampling interval
> > granualrity.  Both patchsets are merged into v6.7-rc1.
> > 
> > Hence, I think you could use 'update_schemes_tried_regions' after you noticed
> > the app's state transition, with DAMOS apply interval of one sampling interval.
> > Then you will get the monitoring results after one sampling interval.  Of
> > course, the snapshot may contain some of background access pattern, but
> > wouldn't made it changed significantly, unless you set aggregation interval too
> > short.
> 
> All other actions will apply at one sampling interval except for the
> `stat` action.
> 
> We use 'update_schemes_tried_regions' after switch to the background. The 
> before_damos_apply callback function will only be set when the next aggregation
> interval arrives. The `tried_regions` will only be updated after setting the 
> callback function. 
> 
> DAMON is still sampling during setting 'update_schemes_tried_regions' to the next
> aggregation time, which is not what we expected. The pseudo-moving-average
> monitoring result can reduce nr_accesees inaccuracy, but age is still being modified
> during this time, so it can't improve this issue.
> 
> Please let me know if my understanding is incorrect. Thank you.

So, 'update_schemes_tried_regions' command is firstly handled by
'damon_sysfs_cmd_request_callback()', which is registered as
after_wmarks_check() and after_aggregation() callback.  Hence
'update_schemes_tried_regions' command is still effectively working in
aggregation interval granularity.  I think this is what you found, right?

If I'm not wrongly understanding your point, I think the concern is valid.  I
think we should make it works in sampling interval granularity.  I will try to
make so.  Would that work for your use case?

> > 
> > > Alternatively, can it return the "last_nr_accesses" and "last_age" values in
> > > tried_regions/<N> directory?
> > 
> > This could also be a good alternative in my think.  Nice idea.  But, because
> > the previously mentioned alternative is already available while this require a
> > bit small but additional changes, could we check if the previously one make
> > sense and works first?  We could revisit this idea if it turns out the previous
> > alternative is not suffice in my opinion.
> > 
> Can you consider adding "last_nr_accesses" and "last_age"  two files in
> 'tried_regions/<N>' directory?

Actually we don't have 'last_age' field, right?  And in case of
'last_nr_accesses', it is a hidden private field, since it is intended to be
accessed by only DAMON core code.  Making it exposed to user means exposing
implementation details, and the mechanism that coupled with an exposed
interface is hard to be changed, so be unflexible.  Hence I'd prefer making
'update_schemes_tried_regions' works in sampling interval granularity, more
than exposing the two information if it works for your use case.


Thanks,
SJ

[...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-26  8:04                         ` SeongJae Park
@ 2024-01-28  9:13                           ` cuiyangpei
  2024-01-28 16:28                             ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2024-01-28  9:13 UTC (permalink / raw)
  To: SeongJae Park, sj, akpm, damon, linux-mm, linux-kernel; +Cc: xiongping1

On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote:
> On Fri, 26 Jan 2024 14:57:06 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > On Mon, Jan 22, 2024 at 09:56:11AM -0800, SeongJae Park wrote:
> > > Hi cuiyangpei,
> > > 
> > > On Mon, 22 Jan 2024 13:46:31 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > 
> > > > On Sun, Dec 03, 2023 at 07:37:45PM +0000, SeongJae Park wrote:
> > > > > On 2023-12-03T13:43:13+08:00 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > > 
> > > > > > On Fri, Dec 01, 2023 at 05:31:12PM +0000, SeongJae Park wrote:
> > > > > > > Hi Cuiyangpei,
> > > > > > > 
> > > > > > > On Fri, 1 Dec 2023 20:25:07 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > > > > > 
> > > > > > > > On Thu, Nov 30, 2023 at 07:44:20PM +0000, SeongJae Park wrote:
> > > > > > > > > Hi Cuiyangpei,
> > > > > > > > > 
> > > > > > > > > On Thu, 30 Nov 2023 17:14:26 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> [...]
> > > > Is there any way to catch sampling result immediately after setting the
> > > > "update_schemes_tried_regions" state?
> > > 
> > > There is no way for exactly doing this.  You would need to proactively collect
> > > snapshots while the app is foreground, and use the latest one that collected
> > > before the app goes background, like recording-based approach would do.
> > > 
> > > I think recent DAMON changes might make an alternative approach available,
> > > though.  From v6.7, DAMON provides pseudo-moving-average monitoring result in
> > > sampling interval granualrity, since patchset "mm/damon: provide pseudo-moving
> > > sum based access rate".  And a followup patchset, namely "mm/damon: implement
> > > DAMOS apply intervals", has made DAMOS works in the sampling interval
> > > granualrity.  Both patchsets are merged into v6.7-rc1.
> > > 
> > > Hence, I think you could use 'update_schemes_tried_regions' after you noticed
> > > the app's state transition, with DAMOS apply interval of one sampling interval.
> > > Then you will get the monitoring results after one sampling interval.  Of
> > > course, the snapshot may contain some of background access pattern, but
> > > wouldn't made it changed significantly, unless you set aggregation interval too
> > > short.
> > 
> > All other actions will apply at one sampling interval except for the
> > `stat` action.
> > 
> > We use 'update_schemes_tried_regions' after switch to the background. The 
> > before_damos_apply callback function will only be set when the next aggregation
> > interval arrives. The `tried_regions` will only be updated after setting the 
> > callback function. 
> > 
> > DAMON is still sampling during setting 'update_schemes_tried_regions' to the next
> > aggregation time, which is not what we expected. The pseudo-moving-average
> > monitoring result can reduce nr_accesees inaccuracy, but age is still being modified
> > during this time, so it can't improve this issue.
> > 
> > Please let me know if my understanding is incorrect. Thank you.
> 
> So, 'update_schemes_tried_regions' command is firstly handled by
> 'damon_sysfs_cmd_request_callback()', which is registered as
> after_wmarks_check() and after_aggregation() callback.  Hence
> 'update_schemes_tried_regions' command is still effectively working in
> aggregation interval granularity.  I think this is what you found, right?
> 
Yes.
> If I'm not wrongly understanding your point, I think the concern is valid.  I
> think we should make it works in sampling interval granularity.  I will try to
> make so.  Would that work for your use case?
> 
It's much better than working in aggregation interval.

I have a question. Why does the 'update_schemes_tried_regions' command need to work
in the sampling time or aggregation time? 'update_schemes_tried_regions' is a
relatively special state that updates the regions that corresponding operation scheme.
Can it be separated from other states and controlled by sysfs node to respond immediately
after being written?

> > > 
> > > > Alternatively, can it return the "last_nr_accesses" and "last_age" values in
> > > > tried_regions/<N> directory?
> > > 
> > > This could also be a good alternative in my think.  Nice idea.  But, because
> > > the previously mentioned alternative is already available while this require a
> > > bit small but additional changes, could we check if the previously one make
> > > sense and works first?  We could revisit this idea if it turns out the previous
> > > alternative is not suffice in my opinion.
> > > 
> > Can you consider adding "last_nr_accesses" and "last_age"  two files in
> > 'tried_regions/<N>' directory?
> 
> Actually we don't have 'last_age' field, right?  And in case of
> 'last_nr_accesses', it is a hidden private field, since it is intended to be
> accessed by only DAMON core code.  Making it exposed to user means exposing
> implementation details, and the mechanism that coupled with an exposed
> interface is hard to be changed, so be unflexible.  Hence I'd prefer making
> 'update_schemes_tried_regions' works in sampling interval granularity, more
> than exposing the two information if it works for your use case.
> 
Ok, I get it. 
> Thanks,
> SJ
> 
> [...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-28  9:13                           ` cuiyangpei
@ 2024-01-28 16:28                             ` SeongJae Park
  2024-01-29 12:13                               ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2024-01-28 16:28 UTC (permalink / raw)
  To: cuiyangpei
  Cc: SeongJae Park, sj, akpm, damon, linux-mm, linux-kernel, xiongping1

On Sun, 28 Jan 2024 17:13:00 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote:
[...]
> > So, 'update_schemes_tried_regions' command is firstly handled by
> > 'damon_sysfs_cmd_request_callback()', which is registered as
> > after_wmarks_check() and after_aggregation() callback.  Hence
> > 'update_schemes_tried_regions' command is still effectively working in
> > aggregation interval granularity.  I think this is what you found, right?
> > 
> Yes.
> > If I'm not wrongly understanding your point, I think the concern is valid.  I
> > think we should make it works in sampling interval granularity.  I will try to
> > make so.  Would that work for your use case?
> > 
> It's much better than working in aggregation interval.

Thank you for confirming.  I will start working on this.

> 
> I have a question. Why does the 'update_schemes_tried_regions' command need to work
> in the sampling time or aggregation time? 'update_schemes_tried_regions' is a
> relatively special state that updates the regions that corresponding operation scheme.
> Can it be separated from other states and controlled by sysfs node to respond immediately
> after being written?

Mainly because the region data is updated by a kdamond thread.  To safely
access the region, the accessor should do some kind of synchronization with the
kdamond thread.  To minimize such synchronization overhead, DAMON let the API
users (kernel components) to register callbacks which kdamond invokes under
specific events including 'after_sampling' or 'after_aggregate'.  Because the
callback is executed in the kdamond thread, callbacks can safely access the
data without additional synchronization.  DAMON sysfs interface is using the
callback mechanism, and hence need to work in the sampling or aggregation
times.


Thanks,
SJ

[...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-28 16:28                             ` SeongJae Park
@ 2024-01-29 12:13                               ` cuiyangpei
  2024-02-06  2:56                                 ` SeongJae Park
  0 siblings, 1 reply; 22+ messages in thread
From: cuiyangpei @ 2024-01-29 12:13 UTC (permalink / raw)
  To: SeongJae Park; +Cc: akpm, damon, linux-mm, linux-kernel, xiongping1

On Sun, Jan 28, 2024 at 08:28:04AM -0800, SeongJae Park wrote:
> On Sun, 28 Jan 2024 17:13:00 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote:
> [...]
> > > So, 'update_schemes_tried_regions' command is firstly handled by
> > > 'damon_sysfs_cmd_request_callback()', which is registered as
> > > after_wmarks_check() and after_aggregation() callback.  Hence
> > > 'update_schemes_tried_regions' command is still effectively working in
> > > aggregation interval granularity.  I think this is what you found, right?
> > > 
> > Yes.
> > > If I'm not wrongly understanding your point, I think the concern is valid.  I
> > > think we should make it works in sampling interval granularity.  I will try to
> > > make so.  Would that work for your use case?
> > > 
> > It's much better than working in aggregation interval.
> 
> Thank you for confirming.  I will start working on this.
> 

Great, looking forward to seeing the progress.

> > 
> > I have a question. Why does the 'update_schemes_tried_regions' command need to work
> > in the sampling time or aggregation time? 'update_schemes_tried_regions' is a
> > relatively special state that updates the regions that corresponding operation scheme.
> > Can it be separated from other states and controlled by sysfs node to respond immediately
> > after being written?
> 
> Mainly because the region data is updated by a kdamond thread.  To safely
> access the region, the accessor should do some kind of synchronization with the
> kdamond thread.  To minimize such synchronization overhead, DAMON let the API
> users (kernel components) to register callbacks which kdamond invokes under
> specific events including 'after_sampling' or 'after_aggregate'.  Because the
> callback is executed in the kdamond thread, callbacks can safely access the
> data without additional synchronization.  DAMON sysfs interface is using the
> callback mechanism, and hence need to work in the sampling or aggregation
> times.
> 
Thank you for the detailed explanation.

> Thanks,
> SJ
> 
> [...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-01-29 12:13                               ` cuiyangpei
@ 2024-02-06  2:56                                 ` SeongJae Park
  2024-02-06  3:26                                   ` cuiyangpei
  0 siblings, 1 reply; 22+ messages in thread
From: SeongJae Park @ 2024-02-06  2:56 UTC (permalink / raw)
  To: cuiyangpei; +Cc: SeongJae Park, akpm, damon, linux-mm, linux-kernel, xiongping1

Hi Cuiyangpei,

On Mon, 29 Jan 2024 20:13:16 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:

> On Sun, Jan 28, 2024 at 08:28:04AM -0800, SeongJae Park wrote:
> > On Sun, 28 Jan 2024 17:13:00 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > 
> > > On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote:
> > [...]
> > > > So, 'update_schemes_tried_regions' command is firstly handled by
> > > > 'damon_sysfs_cmd_request_callback()', which is registered as
> > > > after_wmarks_check() and after_aggregation() callback.  Hence
> > > > 'update_schemes_tried_regions' command is still effectively working in
> > > > aggregation interval granularity.  I think this is what you found, right?
> > > > 
> > > Yes.
> > > > If I'm not wrongly understanding your point, I think the concern is valid.  I
> > > > think we should make it works in sampling interval granularity.  I will try to
> > > > make so.  Would that work for your use case?
> > > > 
> > > It's much better than working in aggregation interval.
> > 
> > Thank you for confirming.  I will start working on this.
> > 
> 
> Great, looking forward to seeing the progress.

Just sent a patch[1] for this.

I also updated DAMON user-space tool, damo, to use this improvement[2].  I hope
that to help others who using DAMON with their own tool to easily understand
how they can get the improvement from this patch.

Also, please feel free to ask any questions and/or help.

[1] https://lore.kernel.org/r/20240206025158.203097-1-sj@kernel.org
[2] https://github.com/awslabs/damo/commit/75af3a1c0b3e79cd3207f0f8df5b5ac39f887450


Thanks,
SJ

[...]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature
  2024-02-06  2:56                                 ` SeongJae Park
@ 2024-02-06  3:26                                   ` cuiyangpei
  0 siblings, 0 replies; 22+ messages in thread
From: cuiyangpei @ 2024-02-06  3:26 UTC (permalink / raw)
  To: SeongJae Park; +Cc: akpm, damon, linux-mm, linux-kernel, xiongping1

On Mon, Feb 05, 2024 at 06:56:59PM -0800, SeongJae Park wrote:
> Hi Cuiyangpei,
> 
> On Mon, 29 Jan 2024 20:13:16 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> 
> > On Sun, Jan 28, 2024 at 08:28:04AM -0800, SeongJae Park wrote:
> > > On Sun, 28 Jan 2024 17:13:00 +0800 cuiyangpei <cuiyangpei@gmail.com> wrote:
> > > 
> > > > On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote:
> > > [...]
> > > > > So, 'update_schemes_tried_regions' command is firstly handled by
> > > > > 'damon_sysfs_cmd_request_callback()', which is registered as
> > > > > after_wmarks_check() and after_aggregation() callback.  Hence
> > > > > 'update_schemes_tried_regions' command is still effectively working in
> > > > > aggregation interval granularity.  I think this is what you found, right?
> > > > > 
> > > > Yes.
> > > > > If I'm not wrongly understanding your point, I think the concern is valid.  I
> > > > > think we should make it works in sampling interval granularity.  I will try to
> > > > > make so.  Would that work for your use case?
> > > > > 
> > > > It's much better than working in aggregation interval.
> > > 
> > > Thank you for confirming.  I will start working on this.
> > > 
> > 
> > Great, looking forward to seeing the progress.
> 
> Just sent a patch[1] for this.
> 
> I also updated DAMON user-space tool, damo, to use this improvement[2].  I hope
> that to help others who using DAMON with their own tool to easily understand
> how they can get the improvement from this patch.
> 
> Also, please feel free to ask any questions and/or help.
> 
> [1] https://lore.kernel.org/r/20240206025158.203097-1-sj@kernel.org
> [2] https://github.com/awslabs/damo/commit/75af3a1c0b3e79cd3207f0f8df5b5ac39f887450
> 
> 
> Thanks,
> SJ
> 
> [...]

Hi SeongJae,

Thank you for sending the patch. I will verify this feature on the phone and reach out
if I have any questions or require assistance.

Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2024-02-06  3:27 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-28  7:34 [PATCH 1/2] mm/damon/sysfs: Implement recording feature cuiyangpei
2023-11-28  7:34 ` [PATCH 2/2] mm/damon/core: add sysfs nodes to set last_nr_accesses weight cuiyangpei
2023-11-28 16:11 ` [PATCH 1/2] mm/damon/sysfs: Implement recording feature kernel test robot
2023-11-28 16:21 ` kernel test robot
2023-11-28 18:57 ` SeongJae Park
2023-11-29 13:13   ` cuiyangpei
2023-11-29 17:10     ` SeongJae Park
2023-11-30  9:14       ` cuiyangpei
2023-11-30 19:44         ` SeongJae Park
2023-12-01 12:25           ` cuiyangpei
2023-12-01 17:31             ` SeongJae Park
2023-12-03  5:43               ` cuiyangpei
2023-12-03 19:37                 ` SeongJae Park
2024-01-22  5:46                   ` cuiyangpei
2024-01-22 17:56                     ` SeongJae Park
2024-01-26  6:57                       ` cuiyangpei
2024-01-26  8:04                         ` SeongJae Park
2024-01-28  9:13                           ` cuiyangpei
2024-01-28 16:28                             ` SeongJae Park
2024-01-29 12:13                               ` cuiyangpei
2024-02-06  2:56                                 ` SeongJae Park
2024-02-06  3:26                                   ` cuiyangpei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).