From nobody Thu Apr 9 23:23:25 2026 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 170AB2116F4; Thu, 5 Mar 2026 05:39:27 +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=1772689167; cv=none; b=h/zj7HzXzY7TZVCfKhZ90UtttItJAIcJ2bi3cH66HerM16JYVLKxuMbC7DVBFKZOmdplTyadjNLNPYHEYbLHDuhcAhKjAWXA3EJP3JVDoCrkd+lxP+HuGI9sCwHiARy1DQ+eTL/Tk/Y9PM354m7dh1gxY/tOaHaawhWRrqig+VA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772689167; c=relaxed/simple; bh=bVVliIOg8qhYd2P4htNiq3HDElr+pou2NiqB1WgEprY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CVeRVkJHgeMmItD6GR83Zj6Dc7n1JNu7qiijsRYaTRI6t6Lk6QvKdTRVT3OOe565gh6tp2VyYBFylUyivbw06Kca2/GM6g07rzDBWdzyYDQ79gBBy9VV0hSuwEYe/LbEDsxe79kfMeFRsiWVIXXtqQ6MFW33ncNID8HhNSdQSWY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EV78gkF0; 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="EV78gkF0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C138EC2BC9E; Thu, 5 Mar 2026 05:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772689166; bh=bVVliIOg8qhYd2P4htNiq3HDElr+pou2NiqB1WgEprY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EV78gkF0MgLzcm2fqzlweoxGrUfkuJ7etBaw1Dbu57ttNfmS/snYwef6oboti0hA+ AXNRLPLVMVvtzKGAKsEdkV75nLk/WjIuLytyXM6916kykgeMk1xfZkPsDVcqlQYiUU +u+PlWwDwhVg+M+3yiPXFvxCi2P+IdUPotWzQFPoMPoa0tbPNjPZr0pmVy+uPuCfEQ efHhwVMBycjy7ltHgnnN0hJ5Q3Vk/GFqutOjI2GQU7eQCxnABFL6yyQRGKH5l81R8P RtQkCHc9KJj7NSfpy/wihuWBvjLJIR37f7U+o8Cj1oRiTT3i3Bn8TOykWC5HKeS3/1 MvkZI423te5xA== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , Yang Yingliang , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 1/5] mm/damon/core: fix wrong end address assignment on walk_system_ram() Date: Wed, 4 Mar 2026 21:39:13 -0800 Message-ID: <20260305053918.83786-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260305053918.83786-1-sj@kernel.org> References: <20260305053918.83786-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" 'struct damon_addr_range' and 'struct resource' represent different types of address ranges. 'damon_addr_range' is for end-open ranges ([start, end)). 'resource' is for fully-closed ranges ([start, end]). But walk_system_ram() is assigning resource->end to damon_addr_range->end without the inclusiveness adjustment. As a result, the function returns an address range that is same as the expected one, but missing the last one byte. The function is being used to find and set the biggest system ram as the default monitoring target for DAMON_RECLAIM and DAMON_LRU_SORT. Missing the last byte of the big range shouldn't be a real problem for the real use cases. That said, the loss is definitely an unintended behavior. Do the correct adjustment. Fixes: 43b0536cb471 ("mm/damon: introduce DAMON-based Reclamation (DAMON_RE= CLAIM)") Signed-off-by: SeongJae Park --- mm/damon/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index de38f2356b72b..db388d05cac3f 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3056,7 +3056,7 @@ static int walk_system_ram(struct resource *res, void= *arg) =20 if (a->end - a->start < resource_size(res)) { a->start =3D res->start; - a->end =3D res->end; + a->end =3D res->end + 1; } return 0; } --=20 2.47.3 From nobody Thu Apr 9 23:23:25 2026 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 37D7926ED40; Thu, 5 Mar 2026 05:39:27 +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=1772689167; cv=none; b=NOtNdU+abpeHuJysYSOJT9Qla5rbkmgUEMF2yQ/AkUIxKv6OUJL5RbvZKiTqJfT6rbTyf02WuW++PYjd5IqywekWU6FW6x++thGWcO7+paezXdkYD7uYSrK9ivPzZdvc5VeQPAlbuAao3U5fhl8htp5HoaZSinsnN3cxUEKkr/0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772689167; c=relaxed/simple; bh=5/X4eJG+KDqPgy0/cAl7n9bW0ZJjnLYl+8/7GajTl5o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u+fZtQxYm8PivOZmiw4bU+oJJF65lDjOqdLEMAnEbU2npzr5XgM3EvUH1au7LqyysIK8lxWjvSuaMWGNdcXzUtCPKk0/eoiB+K4N2TRJBelzQwWWvc9Uyeg5pHpM/gbLd4UcgDejKAIgQ47vnCg1kf7XdN1KWydMEthMS9tHVyI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FYMSt3OK; 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="FYMSt3OK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02D48C2BCAF; Thu, 5 Mar 2026 05:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772689167; bh=5/X4eJG+KDqPgy0/cAl7n9bW0ZJjnLYl+8/7GajTl5o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FYMSt3OKRm2Q/erGqug9bf8DAHBkt2DL6zzKTcvHoWaBbfOocX3WX97d8kmNAHvuj lLoWNXUswuN59Y1esfNNeV4yrTPWR1gJWAhzsiogLPiRb7cYgJsa0a8cxarnHHbc5Z O9Jvv+IAcfAMGv2vrfiFhaKYyRKQy2vqPJgPA5R/dq7wzn8kivgL0Nvgm169rAY1B4 QR7wm4t9G62/zAEZ3Jvw0qskqM1DB07SaGEn7LLEYo2Oee3Rl+gYby2fH97hbsrCuZ M9hABnGurlCM4qF5vldHcdy8si3mBsJsDRSoUm1XA31uivM8kD8JK7cYPPfF2HiTpq nbnb4BEAnGaOg== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 2/5] mm/damon/core: support addr_unit on damon_find_biggest_system_ram() Date: Wed, 4 Mar 2026 21:39:14 -0800 Message-ID: <20260305053918.83786-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260305053918.83786-1-sj@kernel.org> References: <20260305053918.83786-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_find_biggest_system_ram() sets an 'unsigned long' variable with 'resource_size_t' value. This is fundamentally wrong. On environments such as ARM 32 bit machines having LPAE (Large Physical Address Extensions), which DAMON supports, the size of 'unsigned long' may be smaller than that of 'resource_size_t'. It is safe, though, since we restrict the walk to be done only up to ULONG_MAX. DAMON supports the address size gap using 'addr_unit'. We didn't add the support to the function, just to make the initial support change small. Now the support is reasonably settled. This kind of gap is only making the code inconsistent and easy to be confused. Add the support of 'addr_unit' to the function, by letting callers pass the 'addr_unit' and handling it in the function. All callers are passing 'addr_unit' 1, though, to keep the old behavior. Signed-off-by: SeongJae Park --- mm/damon/core.c | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index db388d05cac3f..38c7a919f9bb2 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3052,31 +3052,44 @@ static int kdamond_fn(void *data) =20 static int walk_system_ram(struct resource *res, void *arg) { - struct damon_addr_range *a =3D arg; + struct resource *a =3D arg; =20 - if (a->end - a->start < resource_size(res)) { + if (resource_size(a) < resource_size(res)) { a->start =3D res->start; - a->end =3D res->end + 1; + a->end =3D res->end; } return 0; } =20 +static unsigned long damon_res_to_core_addr(resource_size_t ra, + unsigned long addr_unit) +{ + /* + * Use div_u64() for avoiding linking errors related with __udivdi3, + * __aeabi_uldivmod, or similar problems. This should also improve the + * performance optimization (read div_u64() comment for the detail). + */ + if (sizeof(ra) =3D=3D 8 && sizeof(addr_unit) =3D=3D 4) + return div_u64(ra, addr_unit); + return ra / addr_unit; +} + /* * Find biggest 'System RAM' resource and store its start and end address = in * @start and @end, respectively. If no System RAM is found, returns fals= e. */ static bool damon_find_biggest_system_ram(unsigned long *start, - unsigned long *end) + unsigned long *end, unsigned long addr_unit) =20 { - struct damon_addr_range arg =3D {}; + struct resource res =3D {}; =20 - walk_system_ram_res(0, ULONG_MAX, &arg, walk_system_ram); - if (arg.end <=3D arg.start) + walk_system_ram_res(0, -1, &res, walk_system_ram); + if (res.end < res.start) return false; =20 - *start =3D arg.start; - *end =3D arg.end; + *start =3D damon_res_to_core_addr(res.start, addr_unit); + *end =3D damon_res_to_core_addr(res.end + 1, addr_unit); return true; } =20 @@ -3106,7 +3119,7 @@ int damon_set_region_biggest_system_ram_default(struc= t damon_target *t, return -EINVAL; =20 if (!*start && !*end && - !damon_find_biggest_system_ram(start, end)) + !damon_find_biggest_system_ram(start, end, 1)) return -EINVAL; =20 addr_range.start =3D *start; --=20 2.47.3 From nobody Thu Apr 9 23:23:25 2026 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 65E5C285CAA; Thu, 5 Mar 2026 05:39:27 +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=1772689167; cv=none; b=svzdg6m1YSamrNXDJiEeLSWSfZLrNCSRhdghFJZdf7qfDpun5rfikOmmYgXvvNJVXWW4jMvJtDo4OTZjCLoq07/yaajLbqas9Tb8RTBBNIelTCWrbQIi07ybzmmw9C5TACOtn/J533ESDEG2XLx0wVEQAjZ4K7H7Ak2PwB5Avu4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772689167; c=relaxed/simple; bh=mqrS298EvCt8+EHb5aza5DzJ8VI15nbcF2oVbBOpCLQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c6r+DpWwfmQVpwoJKkv0+f78qjr51d6ifDE6Mb+gMCqRT7yEoimwhUFS5BgLwQBb9LE4rZi8W/fAtlcZ5v7Ks+CL9/QDUhGdFn5TobwpJCy2KgxSF3fEVPRuRggg6iX5+V8EUu4IO43cTiqUMXWU7Pc16MAyZUEAlO+FCIFlxmQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nF76mekm; 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="nF76mekm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 346EEC19423; Thu, 5 Mar 2026 05:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772689167; bh=mqrS298EvCt8+EHb5aza5DzJ8VI15nbcF2oVbBOpCLQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nF76mekm1OnSpkMCOuLU8n63slrkkELJNnTBBSGi7gyGXGB80cedFl3EHHb8qDAnW nfda3ULhAI9uo1HVhqKDvAPhOlQDtlQcWCuDPOh081E7SKGYV2I0YsEJPRENTryrFk DJoqjYgUc6Sihv9ruypthGx91c3+97PumlSHDPeTNpl3Ay5jjZdMnqPC6fU0Y2D4Ym SLoHuT75vr8tLpPW2sAhoxvQwy96BwePlBFH7qpiuABtv23yuTi61qzAIeSzkkchtS 77dI79qAPUnYWOFZJoXUDqTNKpgfA7KA+4tzGciQ73aZYIz5r3BYlwrVkGIvXPTUd3 rAFly0PFSizcw== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 3/5] mm/damon/core: receive addr_unit on damon_set_region_biggest_system_ram_default() Date: Wed, 4 Mar 2026 21:39:15 -0800 Message-ID: <20260305053918.83786-4-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260305053918.83786-1-sj@kernel.org> References: <20260305053918.83786-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_find_biggest_system_ram() was not supporting addr_unit in the past. Hence, its caller, damon_set_region_biggest_system_ram_default(), was also not supporting addr_unit. The previous commit has updated the inner function to support addr_unit. There is no reason to support addr_unit on damon_set_region_biggest_system_ram_default(). Update it to receive addr_unit and handle it inside. Update callers of the function to pass value '1' to addr_unit parameter, though. to avoid unnecessary behavioral change. Signed-off-by: SeongJae Park --- include/linux/damon.h | 1 + mm/damon/core.c | 7 ++++--- mm/damon/lru_sort.c | 1 + mm/damon/reclaim.c | 1 + mm/damon/stat.c | 2 +- 5 files changed, 8 insertions(+), 4 deletions(-) diff --git a/include/linux/damon.h b/include/linux/damon.h index c4095b34f7929..c269b0c93f9df 100644 --- a/include/linux/damon.h +++ b/include/linux/damon.h @@ -985,6 +985,7 @@ int damos_walk(struct damon_ctx *ctx, struct damos_walk= _control *control); =20 int damon_set_region_biggest_system_ram_default(struct damon_target *t, unsigned long *start, unsigned long *end, + unsigned long addr_unit, unsigned long min_region_sz); =20 #endif /* CONFIG_DAMON */ diff --git a/mm/damon/core.c b/mm/damon/core.c index 38c7a919f9bb2..ce19d751f5102 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3099,6 +3099,7 @@ static bool damon_find_biggest_system_ram(unsigned lo= ng *start, * @t: The monitoring target to set the region. * @start: The pointer to the start address of the region. * @end: The pointer to the end address of the region. + * @addr_unit: The address unit for the damon_ctx of @t. * @min_region_sz: Minimum region size. * * This function sets the region of @t as requested by @start and @end. I= f the @@ -3111,7 +3112,7 @@ static bool damon_find_biggest_system_ram(unsigned lo= ng *start, */ int damon_set_region_biggest_system_ram_default(struct damon_target *t, unsigned long *start, unsigned long *end, - unsigned long min_region_sz) + unsigned long addr_unit, unsigned long min_region_sz) { struct damon_addr_range addr_range; =20 @@ -3119,12 +3120,12 @@ int damon_set_region_biggest_system_ram_default(str= uct damon_target *t, return -EINVAL; =20 if (!*start && !*end && - !damon_find_biggest_system_ram(start, end, 1)) + !damon_find_biggest_system_ram(start, end, addr_unit)) return -EINVAL; =20 addr_range.start =3D *start; addr_range.end =3D *end; - return damon_set_regions(t, &addr_range, 1, min_region_sz); + return damon_set_regions(t, &addr_range, addr_unit, min_region_sz); } =20 /* diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c index 7bc5c0b2aea3e..133ea17e258df 100644 --- a/mm/damon/lru_sort.c +++ b/mm/damon/lru_sort.c @@ -345,6 +345,7 @@ static int damon_lru_sort_apply_parameters(void) err =3D damon_set_region_biggest_system_ram_default(param_target, &monitor_region_start, &monitor_region_end, + param_ctx->addr_unit, param_ctx->min_region_sz); if (err) goto out; diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c index 43d76f5bed449..01f2f6cdbcdfe 100644 --- a/mm/damon/reclaim.c +++ b/mm/damon/reclaim.c @@ -251,6 +251,7 @@ static int damon_reclaim_apply_parameters(void) err =3D damon_set_region_biggest_system_ram_default(param_target, &monitor_region_start, &monitor_region_end, + param_ctx->addr_unit, param_ctx->min_region_sz); if (err) goto out; diff --git a/mm/damon/stat.c b/mm/damon/stat.c index 25fb44ccf99d0..f9a2028483b05 100644 --- a/mm/damon/stat.c +++ b/mm/damon/stat.c @@ -181,7 +181,7 @@ static struct damon_ctx *damon_stat_build_ctx(void) goto free_out; damon_add_target(ctx, target); if (damon_set_region_biggest_system_ram_default(target, &start, &end, - ctx->min_region_sz)) + ctx->addr_unit, ctx->min_region_sz)) goto free_out; return ctx; free_out: --=20 2.47.3 From nobody Thu Apr 9 23:23:25 2026 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 9B6832882B7; Thu, 5 Mar 2026 05:39:27 +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=1772689167; cv=none; b=GuiJTryOQlQutKNgD7gm/gxJLOfVo2dTatIUqIGFvxruzZrLwJ8k/UlysNbVaEC4WD4JK9OZAhfz1qvTTqLj5XGgISYZtv4HuZ4hX7xZ357LLKAa6SxG218Lb3aHZvzmPQYg8aw8oFNvhk5eqK2lwc1DnhNzUNwrBLloyuqeeoM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772689167; c=relaxed/simple; bh=kZ7koKz8qVMB9D4eDY9APGuQt2En5THDUr0Tf4sclNI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tWZaDCa7EbCCqi5tUTaUTHY9MOe1tazHPtoGDbJaLSF+JWLErlAVLNwDyyYS4WKvQDGcn3vEb+f6nNdVFIpoct22W5DO92jLvm3OILWi0pFNWm4NXOG7RvMEPgp2wEmqohv4qWHZwInbnXMqbrDA9OCpdF4z1IfMCwFDu3UbaXo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eFxfg2G0; 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="eFxfg2G0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 658DBC116C6; Thu, 5 Mar 2026 05:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772689167; bh=kZ7koKz8qVMB9D4eDY9APGuQt2En5THDUr0Tf4sclNI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eFxfg2G0MgGzE6YO6yM0TECJsgz7CkfK1YkIMVCHdR2GmW+C9Ip9QJk6GN6HOVUDp FQ1+rIWi4WnjADGn5r1raE8kZscNrzDg1SRHnLh4b6/YbAwj9/kMKnFu2IRJDYVZac w7tBvrdg33heRurOcaFdAz40Pf0Dd4wJL7q6OVtiQ8GaVFu4mwm8UwhuvyHOvjMmPi Ba+DhAOG1FKH8YkqbKX1LoHmTO4zbpUhzRoSbMIVhuV9chljNyY2b/jOsSb6PHqlte QXrL9p5SSA5wA7QtlsLl36i8NJqHDeKbgkbcGs4oMtFUOqJ6T8DzGKUe4qovPMuImp VsLErYTguWahQ== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 4/5] mm/damon/reclaim: respect addr_unit on default monitoring region setup Date: Wed, 4 Mar 2026 21:39:16 -0800 Message-ID: <20260305053918.83786-5-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260305053918.83786-1-sj@kernel.org> References: <20260305053918.83786-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" In the past, damon_set_region_biggest_system_ram_default(), which is the core function for setting the default monitoring target region of DAMON_RECLAIM, didn't support addr_unit. Hence DAMON_RECLAIM was silently ignoring users input for addr_unit when the users don't explicitly set the monitoring target regions, and therefore the default target region is being used. No real problem from the ignorance was reported so far. But, the implicit rule is only making things confusing. Also, the default target region setup function is updated to supports addr_unit. Hence there is no reason to keep ignoring it. Respect the user input addr_unit for the default target monitoring region use case. Signed-off-by: SeongJae Park --- mm/damon/reclaim.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c index 01f2f6cdbcdfe..86da147786583 100644 --- a/mm/damon/reclaim.c +++ b/mm/damon/reclaim.c @@ -201,12 +201,6 @@ static int damon_reclaim_apply_parameters(void) if (err) return err; =20 - /* - * If monitor_region_start/end are unset, always silently - * reset addr_unit to 1. - */ - if (!monitor_region_start && !monitor_region_end) - addr_unit =3D 1; param_ctx->addr_unit =3D addr_unit; param_ctx->min_region_sz =3D max(DAMON_MIN_REGION_SZ / addr_unit, 1); =20 --=20 2.47.3 From nobody Thu Apr 9 23:23:25 2026 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 D0860289374; Thu, 5 Mar 2026 05:39:27 +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=1772689167; cv=none; b=YlkC3MH4t8F6bgV0MdqiKWk69lhbLelaWXZjl7DNSJcdyoOgsQzMAMzqiVySrEmL8fI5RrDwr8oaN8RUQn4qVS8z8AH3Mf0uBZ51eVCQNZQ0rK1gi7N4Lg/3jNr2xdZyt0USqv8nWNPaPyl6NwZudLqWfRwtjhgyBiLHFxCxT5E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772689167; c=relaxed/simple; bh=r27GMhiObkYnb8XTcWLlOteq5MZpTGOd9BxwRdhYsfM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a+MThU788et5MkSC1av9gF0wWh7egHH5LN5O5Sl+Dezu/LfxTB08KiBRoFPsWsGUnVfdVn0WUs0N3/IVtVnM9cvcWdV5rL+zDcZTN1nQ/itwT+5H26CkRLGyd2U++j5XCY4OV4o6zLrlYfAwdRdsdZmmx9ZSfiPaCx6Tbx8csZs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C4xWRRtq; 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="C4xWRRtq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97F38C19423; Thu, 5 Mar 2026 05:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772689167; bh=r27GMhiObkYnb8XTcWLlOteq5MZpTGOd9BxwRdhYsfM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C4xWRRtqOg/akTqggqkq/gixQ1zv0LBRIeNg/LuXjhW9SEVTzUXzgYyfEHiK9wPvA MyoYMALP+2/u75UX4LTN8Yr2Z7hLBRSQMdgLgGzsqJSdPl7f6mxtWiADkFtdC7skj3 EK2qR/3CIW/BgZKs0nNgLs4qLsqDqftcEIXFm+RiY+gaTHHn8m0oWvmCeb/+lTn7CO iVQrlYycQMcvdgCeEUn43Bb4Bj0W48KhjiwRXbzf4vw1lYwJyHHBIiPuGjEfMW3LKf LCpcjA8i/fPyA8QV9XTeL3MQcXTHoHnmoO4i+cfhIItHcpWNcQeD/L7wYsJshESX6T 7PAiTkXSCyHNA== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 5/5] mm/damon/lru_sort: respect addr_unit on default monitoring region setup Date: Wed, 4 Mar 2026 21:39:17 -0800 Message-ID: <20260305053918.83786-6-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260305053918.83786-1-sj@kernel.org> References: <20260305053918.83786-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" In the past, damon_set_region_biggest_system_ram_default(), which is the core function for setting the default monitoring target region of DAMON_LRU_SORT, didn't support addr_unit. Hence DAMON_LRU_SORT was silently ignoring users input for addr_unit when the users don't explicitly set the monitoring target regions, and therefore the default target region is being used. No real problem from the ignorancee was reported so far. But, the implicit rule is only making things confusing. Also, the default target region setup function is updated to supports addr_unit. Hence there is no reason to keep ignoring it. Respect the user input addr_unit for the default target monitoring region use case. Signed-off-by: SeongJae Park --- mm/damon/lru_sort.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c index 133ea17e258df..554559d729760 100644 --- a/mm/damon/lru_sort.c +++ b/mm/damon/lru_sort.c @@ -291,12 +291,6 @@ static int damon_lru_sort_apply_parameters(void) if (err) return err; =20 - /* - * If monitor_region_start/end are unset, always silently - * reset addr_unit to 1. - */ - if (!monitor_region_start && !monitor_region_end) - addr_unit =3D 1; param_ctx->addr_unit =3D addr_unit; param_ctx->min_region_sz =3D max(DAMON_MIN_REGION_SZ / addr_unit, 1); =20 --=20 2.47.3