From nobody Sun Dec 14 05:55:18 2025 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88F262FC02F for ; Thu, 30 Oct 2025 02:07:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761790043; cv=none; b=uMjsOsHKJYg3FAdJfvwhOMj/ZY9KGMrxnkZCnjUGaRyfy6aw0gX24Ntw3pl+MLuTnQZXmh3feqBH3w2yBi/Jumgbhsyts96/x8AOWDv/xW9Kg3Gyt+UlrpA0kClXDSVWzw/ku+UXf5FKQN9rWY8D3ugSvhQC2nNoOyWZwVTQcIs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761790043; c=relaxed/simple; bh=+NPqMVrB2l1gWDAaWXGohZUXYcRy4anLZIaEBuvl7wI=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YyuJiA3KDQ8DmnEcQeRbd8Qxz0agRARWIJaVrm5MrLdr/w6e3xnvyRZZCsaDXyKZXKqjaVqzFUfHoYWLzDQ0yB1Q8No0jIuRPmusMhdBh8uZqNh9Gg5qFNjqZ1Bdnj+kJiCiQeMMybwMoRJzaYtM14wR5aK+KNIPDMsvkBzLoGU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=l+XDWrmA; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="l+XDWrmA" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Fr+3CDNz64iBwWCR8OXL6QiRv6BkJHD6nWLy2Y5mJRg=; b=l+XDWrmA89J7sFLQjzNeZ5TUea1iYtJx18bPrE4Pn5sL5xmly5KhYipxZKWVsTS2f/ITQU7l2 G3K/K2+vhp326P7vtkK2klRq4NxaIQ0Uilnfw+rz844UsH7YAwMqDFuX19fQrUf4J8cfoJ+AK/O pmL6gmdQODnoSeH4QJomBc4= Received: from mail.maildlp.com (unknown [172.19.88.214]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4cxnXz4xzmzLlSH; Thu, 30 Oct 2025 10:06:43 +0800 (CST) Received: from dggpemf200018.china.huawei.com (unknown [7.185.36.31]) by mail.maildlp.com (Postfix) with ESMTPS id 02D901A016C; Thu, 30 Oct 2025 10:07:13 +0800 (CST) Received: from huawei.com (10.50.85.135) by dggpemf200018.china.huawei.com (7.185.36.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 30 Oct 2025 10:07:12 +0800 From: Quanmin Yan To: CC: , , , , , , Subject: [PATCH v2 1/2] mm/damon/stat: change last_refresh_jiffies to a global variable Date: Thu, 30 Oct 2025 10:07:45 +0800 Message-ID: <20251030020746.967174-2-yanquanmin1@huawei.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251030020746.967174-1-yanquanmin1@huawei.com> References: <20251030020746.967174-1-yanquanmin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To dggpemf200018.china.huawei.com (7.185.36.31) In DAMON_STAT's damon_stat_damon_call_fn(), time_before_eq() is used to avoid unnecessarily frequent stat update. On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make jiffies wrap bugs appear earlier. However, this causes time_before_eq() in DAMON_STAT to unexpectedly return true during the first 5 minutes after boot on 32-bit systems (see [1] for more explanation, which fixes another jiffies-related issue before). As a result, DAMON_STAT does not update any monitoring results during that period, which becomes more confusing when DAMON_STAT_ENABLED_DEFAULT is enabled. There is also an issue unrelated to the system=E2=80=99s word size[2]: if t= he user stops DAMON_STAT just after last_refresh_jiffies is updated and restarts it after 5 seconds or a longer delay, last_refresh_jiffies will retain an older value, causing time_before_eq() to return false and the update to happen earlier than expected. Fix these issues by making last_refresh_jiffies a global variable and initializing it each time DAMON_STAT is started. [1] https://lkml.kernel.org/r/20250822025057.1740854-1-ekffu200098@gmail.com [2] https://lore.kernel.org/all/20251028143250.50144-1-sj@kernel.org/ Fixes: fabdd1e911da ("mm/damon/stat: calculate and expose estimated memory = bandwidth") Suggested-by: SeongJae Park Signed-off-by: Quanmin Yan Reviewed-by: SeongJae Park --- mm/damon/stat.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/damon/stat.c b/mm/damon/stat.c index 6c4503d2aee3..ed8e3629d31a 100644 --- a/mm/damon/stat.c +++ b/mm/damon/stat.c @@ -46,6 +46,8 @@ MODULE_PARM_DESC(aggr_interval_us, =20 static struct damon_ctx *damon_stat_context; =20 +static unsigned long damon_stat_last_refresh_jiffies; + static void damon_stat_set_estimated_memory_bandwidth(struct damon_ctx *c) { struct damon_target *t; @@ -130,13 +132,12 @@ static void damon_stat_set_idletime_percentiles(struc= t damon_ctx *c) static int damon_stat_damon_call_fn(void *data) { struct damon_ctx *c =3D data; - static unsigned long last_refresh_jiffies; =20 /* avoid unnecessarily frequent stat update */ - if (time_before_eq(jiffies, last_refresh_jiffies + + if (time_before_eq(jiffies, damon_stat_last_refresh_jiffies + msecs_to_jiffies(5 * MSEC_PER_SEC))) return 0; - last_refresh_jiffies =3D jiffies; + damon_stat_last_refresh_jiffies =3D jiffies; =20 aggr_interval_us =3D c->attrs.aggr_interval; damon_stat_set_estimated_memory_bandwidth(c); @@ -211,6 +212,8 @@ static int damon_stat_start(void) err =3D damon_start(&damon_stat_context, 1, true); if (err) return err; + + damon_stat_last_refresh_jiffies =3D jiffies; call_control.data =3D damon_stat_context; return damon_call(damon_stat_context, &call_control); } --=20 2.43.0 From nobody Sun Dec 14 05:55:18 2025 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C1B12DFF18 for ; Thu, 30 Oct 2025 02:07:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761790038; cv=none; b=mu22/UExDT6o/8EiixVYtGSMInQnKPbmrloHxdcYYYVioQm0NPjSgSRdQWJmpmA7NPBgYhvDXoyQ7MC0M4z+c1HyGoXaEc4cY0LcvpK2pI+dKdMvEN06k9DiUOgU9GmZfnlSKlNyYHS1oP+blUTLuUrL9m5OHsnz7l/8wZ83RX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761790038; c=relaxed/simple; bh=eNxP1kxYJUGJIDwdHoCty2HweZbHrUTXcGaUWNkzXjQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jYv9IaHn949B1RqQpeU/xlKK/DrFH7erhWQ4SlAGHtJ/TzbRbtGtyakqCGAsv9epHipZkddIZDxfEDp4Vq3UNtykgVphb2yPM4xlxyTt9n9mXPzTWfQfwoSou8LPtQdsOIRH8k20+rgPFNGdNsI5tiT+/SvPDOOnUZX8+0CZY+U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=YU8+A9Fh; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="YU8+A9Fh" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=3lQbFuRe/0xuO7BK5YDklifoaPlkhacuORBMPC4fqSg=; b=YU8+A9Fh1PyjGZNM4lKgkU0lc73vXHuAqphJpw2tqmXf+puEYsHp62CbDSEExG7VGTh2SEIpj /VnDSz/9BtQG+PH3GEvbe1YV+yyB/Rb4JFQsXQneGlXVVu+/pvTTBM+ppQ+dzI+JwjO7dXSsSBg h+02tlQwpwDUFGk48zj2O2Y= Received: from mail.maildlp.com (unknown [172.19.88.194]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4cxnX14ptSzpSv6; Thu, 30 Oct 2025 10:05:53 +0800 (CST) Received: from dggpemf200018.china.huawei.com (unknown [7.185.36.31]) by mail.maildlp.com (Postfix) with ESMTPS id 7FB9A1400CA; Thu, 30 Oct 2025 10:07:13 +0800 (CST) Received: from huawei.com (10.50.85.135) by dggpemf200018.china.huawei.com (7.185.36.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 30 Oct 2025 10:07:12 +0800 From: Quanmin Yan To: CC: , , , , , , Subject: [PATCH v2 2/2] mm/damon/sysfs: change next_update_jiffies to a global variable Date: Thu, 30 Oct 2025 10:07:46 +0800 Message-ID: <20251030020746.967174-3-yanquanmin1@huawei.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251030020746.967174-1-yanquanmin1@huawei.com> References: <20251030020746.967174-1-yanquanmin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To dggpemf200018.china.huawei.com (7.185.36.31) In DAMON=E2=80=99s damon_sysfs_repeat_call_fn(), time_before() is used to c= ompare the current jiffies with next_update_jiffies to determine whether to update the sysfs files at this moment. On 32-bit systems, the kernel initializes jiffies to "-5 minutes" to make jiffies wrap bugs appear earlier. However, this causes time_before() in damon_sysfs_repeat_call_fn() to unexpectedly return true during the first 5 minutes after boot on 32-bit systems (see [1] for more explanation, which fixes another jiffies-related issue before). As a result, DAMON does not update sysfs files during that period. There is also an issue unrelated to the system=E2=80=99s word size[2]: if t= he user stops DAMON just after next_update_jiffies is updated and restarts it after 'refresh_ms' or a longer delay, next_update_jiffies will retain an older value, causing time_before() to return false and the update to happen earlier than expected. Fix these issues by making next_update_jiffies a global variable and initializing it each time DAMON is started. [1] https://lkml.kernel.org/r/20250822025057.1740854-1-ekffu200098@gmail.com [2] https://lore.kernel.org/all/20251029013038.66625-1-sj@kernel.org/ Fixes: d809a7c64ba8 ("mm/damon/sysfs: implement refresh_ms file internal wo= rk") Suggested-by: SeongJae Park Signed-off-by: Quanmin Yan Reviewed-by: SeongJae Park --- mm/damon/sysfs.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c index 43ee9ce4dd84..e2bd2d7becdd 100644 --- a/mm/damon/sysfs.c +++ b/mm/damon/sysfs.c @@ -1601,16 +1601,17 @@ static struct damon_ctx *damon_sysfs_build_ctx( return ctx; } =20 +static unsigned long damon_sysfs_next_update_jiffies; + static int damon_sysfs_repeat_call_fn(void *data) { struct damon_sysfs_kdamond *sysfs_kdamond =3D data; - static unsigned long next_update_jiffies; =20 if (!sysfs_kdamond->refresh_ms) return 0; - if (time_before(jiffies, next_update_jiffies)) + if (time_before(jiffies, damon_sysfs_next_update_jiffies)) return 0; - next_update_jiffies =3D jiffies + + damon_sysfs_next_update_jiffies =3D jiffies + msecs_to_jiffies(sysfs_kdamond->refresh_ms); =20 if (!mutex_trylock(&damon_sysfs_lock)) @@ -1656,6 +1657,9 @@ static int damon_sysfs_turn_damon_on(struct damon_sys= fs_kdamond *kdamond) } kdamond->damon_ctx =3D ctx; =20 + damon_sysfs_next_update_jiffies =3D + jiffies + msecs_to_jiffies(kdamond->refresh_ms); + repeat_call_control->fn =3D damon_sysfs_repeat_call_fn; repeat_call_control->data =3D kdamond; repeat_call_control->repeat =3D true; --=20 2.43.0