Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   SeongJae Park <sjpark@amazon.com>
To:     <akpm@linux-foundation.org>
CC:     SeongJae Park <sjpark@amazon.de>, <Jonathan.Cameron@Huawei.com>,
        <aarcange@redhat.com>, <acme@kernel.org>,
        <alexander.shishkin@linux.intel.com>, <amit@kernel.org>,
        <benh@kernel.crashing.org>, <brendan.d.gregg@gmail.com>,
        <brendanhiggins@google.com>, <cai@lca.pw>,
        <colin.king@canonical.com>, <corbet@lwn.net>, <david@redhat.com>,
        <dwmw@amazon.com>, <elver@google.com>, <fan.du@intel.com>,
        <foersleo@amazon.de>, <gthelen@google.com>, <irogers@google.com>,
        <jolsa@redhat.com>, <kirill@shutemov.name>, <mark.rutland@arm.com>,
        <mgorman@suse.de>, <minchan@kernel.org>, <mingo@redhat.com>,
        <namhyung@kernel.org>, <peterz@infradead.org>,
        <rdunlap@infradead.org>, <riel@surriel.com>, <rientjes@google.com>,
        <rostedt@goodmis.org>, <rppt@kernel.org>, <sblbir@amazon.com>,
        <shakeelb@google.com>, <shuah@kernel.org>, <sj38.park@gmail.com>,
        <snu@amazon.de>, <vbabka@suse.cz>, <vdavydov.dev@gmail.com>,
        <yang.shi@linux.alibaba.com>, <ying.huang@intel.com>,
        <zgf574564920@gmail.com>, <linux-damon@amazon.com>,
        <linux-mm@kvack.org>, <linux-doc@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: [RFC PATCH 1/2] mm/damon: Put more information in kdamond thread name
Date:   Tue, 15 Sep 2020 20:02:23 +0200
Message-ID: <20200915180225.17439-2-sjpark@amazon.com>
In-Reply-To: <20200915180225.17439-1-sjpark@amazon.com>
References: <20200915180225.17439-1-sjpark@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: SeongJae Park <sjpark@amazon.de>

While multiple kdamond threads can run, it is hard to distinguish each
thread as all kdamond threads has same name, 'kdamond'.  This commit
puts more information including if it is spawned from the user context
(via the debugfs interface) and for what context it is running.  The
format of the name is:

    kdamond.<current pid>.<# of context>

If it is not spawned from the user context, <current pid> becomes 0.
Using this information, for example, the user space could easily account
CPU usage of DAMON that they requested in fine granularity.

Signed-off-by: SeongJae Park <sjpark@amazon.de>
---
 mm/damon.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/damon.c b/mm/damon.c
index c92e4c76aa53..abb8c07a4c7d 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -1552,6 +1552,8 @@ static bool damon_kdamond_running(struct damon_ctx *ctx)
  * __damon_start() - Starts monitoring with given context.
  * @ctx:	monitoring context
  *
+ * This function should be called while damon_lock is hold.
+ *
  * Return: 0 on success, negative error code otherwise.
  */
 static int __damon_start(struct damon_ctx *ctx)
@@ -1562,7 +1564,8 @@ static int __damon_start(struct damon_ctx *ctx)
 	if (!ctx->kdamond) {
 		err = 0;
 		ctx->kdamond_stop = false;
-		ctx->kdamond = kthread_create(kdamond_fn, ctx, "kdamond");
+		ctx->kdamond = kthread_create(kdamond_fn, ctx, "kdamond.%d.%d",
+				current ? current->pid : 0, nr_running_ctxs);
 		if (IS_ERR(ctx->kdamond))
 			err = PTR_ERR(ctx->kdamond);
 		else
-- 
2.17.1