From nobody Sun Nov 24 22:45:07 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D05F61C9DED; Thu, 31 Oct 2024 18:38:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730399882; cv=none; b=QQoJGS9QtFpKpFT9FpCmPbvyTAImlenH+PriL3vu8/7lUyqAdwZt2wna+u7P1+XM+rXhtASTh/cqDL+s5di+gTtzSLjR1gvW8EFyJklq8i1lDlQTL9p3euMi5HZ7+KxeCe7tEcRdl0txDFqUz+kU9RJKvhYbKvXZ8qqzry+mb6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730399882; c=relaxed/simple; bh=hzCrs3U1wpfuL1mByOLcpS5v+HB/qTe71dwMaFfYxG4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Y2jNUlQh2UnbCFb/152wmhajhEsBywnz0GeVQYVCZmf/8C9HZPfVb0tgqiVGWMtAyyXnJy/hn7lxbNCAkccv3cmFP6E5AqKwJnq1MIldguDTVgB/OVDBO7ulAOyHxbJ/b2DNigPzlkSiGYcKAMOyUI027itC0/v/nvVRkx4n0Ak= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uaImNOts; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uaImNOts" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3709EC4CEC3; Thu, 31 Oct 2024 18:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730399882; bh=hzCrs3U1wpfuL1mByOLcpS5v+HB/qTe71dwMaFfYxG4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uaImNOtsGoHYSbe1m2EJckQzyLxi20TlzKdFyg4I1+pz0azw903+1CWJfhtelXv0u rcmY6Tr9ux9gPygaxzdwk1bV7udBlBRiDKlIsfhKDBZhcfcA6I/SdSdIoICNuN8TX+ pzRDVujFnJgRi0HCN+TetdtHbetKZXEinbaPYwbUPVW/zNsnnQL0SdYaHn9RpShJZJ 5T/3UjPh+y4Kb/cah3MjgKf2HLyf/Sy44sv6B8pcM+LNa2ddsCwKskJmsLNAFEpz3l i5KU3LKJzrL+Ix/EfuTA3m7z819N72lK00vZ9X/hxI8SQSf+WtpLumzPg0HE+BkcFJ fcH+N5mWhcE5Q== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, stable@vger.kernel.org Subject: [PATCH 1/2] mm/damon/core: handle zero {aggregation,ops_update} intervals Date: Thu, 31 Oct 2024 11:37:56 -0700 Message-Id: <20241031183757.49610-2-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241031183757.49610-1-sj@kernel.org> References: <20241031183757.49610-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" DAMON's logics to determine if this is the time to do aggregation and ops update assumes next_{aggregation,ops_update}_sis are always set larger than current passed_sample_intervals. And therefore it further assumes continuously incrementing passed_sample_intervals every sampling interval will make it reaches to the next_{aggregation,ops_update}_sis in future. The logic therefore make the action and update next_{aggregation,ops_updaste}_sis only if passed_sample_intervals is same to the counts, respectively. If Aggregation interval or Ops update interval are zero, however, next_aggregation_sis or next_ops_update_sis are set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_{aggregation,ops_update}_sis check. Hence, passed_sample_intervals becomes larger than next_{aggregation,ops_update}_sis, and the logic says it is not the time to do the action and update next_{aggregation,ops_update}_sis forever, until an overflow happens. In other words, DAMON stops doing aggregations or ops updates effectively forever, and users cannot get monitoring results. Based on the documents and the common sense, a reasonable behavior for such inputs is doing an aggregation and an ops update for every sampling interval. Handle the case by removing the assumption. Note that this could incur particular real issue for DAMON sysfs interface users, in case of zero Aggregation interval. When user starts DAMON with zero Aggregation interval and asks online DAMON parameter tuning via DAMON sysfs interface, the request is handled by the aggregation callback. Until the callback finishes the work, the user who requested the online tuning just waits. Hence, the user will be stuck until the passed_sample_intervals overflows. Fixes: 4472edf63d66 ("mm/damon/core: use number of passed access sampling a= s a timer") Cc: # 6.7.x Signed-off-by: SeongJae Park --- mm/damon/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 27745dcf855f..931526fb2d2e 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2014,7 +2014,7 @@ static int kdamond_fn(void *data) if (ctx->ops.check_accesses) max_nr_accesses =3D ctx->ops.check_accesses(ctx); =20 - if (ctx->passed_sample_intervals =3D=3D next_aggregation_sis) { + if (ctx->passed_sample_intervals >=3D next_aggregation_sis) { kdamond_merge_regions(ctx, max_nr_accesses / 10, sz_limit); @@ -2032,7 +2032,7 @@ static int kdamond_fn(void *data) =20 sample_interval =3D ctx->attrs.sample_interval ? ctx->attrs.sample_interval : 1; - if (ctx->passed_sample_intervals =3D=3D next_aggregation_sis) { + if (ctx->passed_sample_intervals >=3D next_aggregation_sis) { ctx->next_aggregation_sis =3D next_aggregation_sis + ctx->attrs.aggr_interval / sample_interval; =20 @@ -2042,7 +2042,7 @@ static int kdamond_fn(void *data) ctx->ops.reset_aggregated(ctx); } =20 - if (ctx->passed_sample_intervals =3D=3D next_ops_update_sis) { + if (ctx->passed_sample_intervals >=3D next_ops_update_sis) { ctx->next_ops_update_sis =3D next_ops_update_sis + ctx->attrs.ops_update_interval / sample_interval; --=20 2.39.5 From nobody Sun Nov 24 22:45:07 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 ACD911C9ED2; Thu, 31 Oct 2024 18:38:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730399883; cv=none; b=NH2ftcEXbuhvDsz+5UZIiIcpmep7qQNX5OHETctpm0i+R0InpoKVlIqONsDQlW+d8gN60Drge/B5OYSCi53oJDcxy5OPNtMl4FI8k2eetGUkqooSKrUQiq0xQOukNq1iJOn2yBo9k5tuq+P1sMqAXtJrouLYMHtjB79KO8tGOfY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730399883; c=relaxed/simple; bh=L0OOFAcas3acRh+BRifsG3N6Sbsa4Qrr4fl+oy8M5uA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=TiE+DMCkSNpZfD6WnAr2l0+E3GmgpT5aKxE9XlroBbT/d/U/TZOoAZ1FN40Konplg1zf270TSFrLmRyj+h9JtBnX4Ee2Ew1eWAjenAEzQ97/HDMmWmhBF3uaUYdQpEVEcCUwh7p2F3nT5PgseD5IL7sCHj/XeK/8m7uGaYwNS5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g0P16FYT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g0P16FYT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F704C4CED1; Thu, 31 Oct 2024 18:38:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730399883; bh=L0OOFAcas3acRh+BRifsG3N6Sbsa4Qrr4fl+oy8M5uA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g0P16FYTS9DnqQ14GhTEt6IbNDNM+8nRMCJYKMr4VnOSTv+27cQyXSIbjCefOL9KZ mDyvoyTBeBxmslifg0hATNkapdR1tV6Z+zWEvC75ed4xObZEwlahgRv4dadBxmuclo z1oj7KAkBMuqJplhnZ9rvzT22HwZyV9LxGiF4nUT6DGZwq8qNQYjXVLj9HNH7u76iL 92Go4qFwtmoG9dJV02X4z8D6l0lMzPzjO5C8ptBvgUK0t60WBe85iP3UPEBImoHUuX PNwI1+0H2G3T6weBaN3q4A+1Ue7MsGmNTLSm5tKvoPkEDOV2nJFchrQkWsb5J3Ry17 +BLbh7BR8+bCA== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, stable@vger.kernel.org Subject: [PATCH 2/2] mm/damon/core: handle zero schemes apply interval Date: Thu, 31 Oct 2024 11:37:57 -0700 Message-Id: <20241031183757.49610-3-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241031183757.49610-1-sj@kernel.org> References: <20241031183757.49610-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" DAMON's logics to determine if this is the time to apply damos schemes assumes next_apply_sis is always set larger than current passed_sample_intervals. And therefore assume continuously incrementing passed_sample_intervals will make it reaches to the next_apply_sis in future. The logic hence does apply the scheme and update next_apply_sis only if passed_sample_intervals is same to next_apply_sis. If Schemes apply interval is set as zero, however, next_apply_sis is set same to current passed_sample_intervals, respectively. And passed_sample_intervals is incremented before doing the next_apply_sis check. Hence, next_apply_sis becomes larger than next_apply_sis, and the logic says it is not the time to apply schemes and update next_apply_sis. In other words, DAMON stops applying schemes until passed_sample_intervals overflows. Based on the documents and the common sense, a reasonable behavior for such inputs would be applying the schemes for every sampling interval. Handle the case by removing the assumption. Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interv= al") Cc: # 6.7.x Signed-off-by: SeongJae Park --- mm/damon/core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 931526fb2d2e..511c3f61ab44 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -1412,7 +1412,7 @@ static void damon_do_apply_schemes(struct damon_ctx *= c, damon_for_each_scheme(s, c) { struct damos_quota *quota =3D &s->quota; =20 - if (c->passed_sample_intervals !=3D s->next_apply_sis) + if (c->passed_sample_intervals < s->next_apply_sis) continue; =20 if (!s->wmarks.activated) @@ -1636,7 +1636,7 @@ static void kdamond_apply_schemes(struct damon_ctx *c) bool has_schemes_to_apply =3D false; =20 damon_for_each_scheme(s, c) { - if (c->passed_sample_intervals !=3D s->next_apply_sis) + if (c->passed_sample_intervals < s->next_apply_sis) continue; =20 if (!s->wmarks.activated) @@ -1656,9 +1656,9 @@ static void kdamond_apply_schemes(struct damon_ctx *c) } =20 damon_for_each_scheme(s, c) { - if (c->passed_sample_intervals !=3D s->next_apply_sis) + if (c->passed_sample_intervals < s->next_apply_sis) continue; - s->next_apply_sis +=3D + s->next_apply_sis =3D c->passed_sample_intervals + (s->apply_interval_us ? s->apply_interval_us : c->attrs.aggr_interval) / sample_interval; } --=20 2.39.5