From nobody Wed Apr 8 02:54:44 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 915C03290C9; Wed, 11 Mar 2026 05:29:31 +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=1773206971; cv=none; b=dI6fbn9UvDThn3KOdGOeYR/Pi6UJtzy7lw5EtTL5HpaFAJmu8Z2v9ILvSCuCinZmKfydNKsp0H+EapgjuQbAN0wW1p9iQGotEOAuM9kFz0h0wlBUOT6+n/QJEV4DtKHBqlpgW6LafotpDPul3i7RgS2Nd3WgHcY/l7R+tL/WK6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773206971; c=relaxed/simple; bh=7cYdKplDL21iIsxLZsDyZKirI/10a9vKJC4T+MgvDTg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FHqMW709qmkSnrwBvscxvUVjJz2/4GDv2h0d0ExhHZods/VR+5jFPQiPkIdaUhsbHAPnwEJx2zhb3ugn8f+JTU5ZucZ7SJPs0eoji4xaST+jXebOwo6Zuir/APYXJNcQN4uZPKcl4zjNGUfzqUR+O8lbL4G2Al87i5h6hIJzBLY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JWw+fn4S; 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="JWw+fn4S" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B62CC2BCAF; Wed, 11 Mar 2026 05:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773206971; bh=7cYdKplDL21iIsxLZsDyZKirI/10a9vKJC4T+MgvDTg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JWw+fn4SeVXEJyK2LlrMabr7MCW8ceh7oXjafpjdByQY6fgdPUa+Au9wo5OyE8FaG u0njAgR7wJl/LdCtj6lXrOH5pM4iis3sXjoRuFy5lxWTqhF65RgKVC1qClZL88/Qj/ OLPv8oxEwwHcv5ki7k9mjBRR15mtR7yMh7LqojsZxaE/rXxnf6I9a+9QSW4xwmkvWw hie/G4BUkhn2jGp8Omc/x5lzoo9JKEf4I53UNbxcxVfjb16d+5NVxh6PNV2sJq0hRt HAze4P+5OHWMX4Ojp70CVdfK9iIY+nUX0H/5ZDhKrfkAbNfopx92OhAVzj9sIeEAC+ iMJts6isaoOag== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Yang Yingliang , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1/5] mm/damon/core: fix wrong end address assignment on walk_system_ram() Date: Tue, 10 Mar 2026 22:29:22 -0700 Message-ID: <20260311052927.93921-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260311052927.93921-1-sj@kernel.org> References: <20260311052927.93921-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 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 2e36024d99506..3925720a172a6 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3060,7 +3060,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 Wed Apr 8 02:54:44 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 B036732D7F1; Wed, 11 Mar 2026 05:29:31 +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=1773206971; cv=none; b=poWKV5plwJilJcmzw/k2RwgplCzmhRyokghCTPGN1gt2GeqIzdCpAhxdC1jXmdpPRLUdoeFprZw1GLvdZ1qZD3vy16YhfGdVfTQ4gRiSxDRyTTLVhV4uo5/czTOLwhuSJYqZ7TavaXm999ao+tN3bze2HDZAHDLazuonXgI6SVQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773206971; c=relaxed/simple; bh=aGbllmaaq9J7Qd8uyVbLEXseWZd1bfmXTBQJFAjpS5A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=atq+I02fo3hVU39XLKzz9rTZfTkamZm6kiUXORd436PAZVHty/EwgitcgfuJd2xFmvRI/eH+bY7mb/mtbabhiYTWCBgH/P39MhAvEyJT7LJZuUOLKadwY0wjCdN59VDAUvCIZe7bkLHZbRU2V69Hjs+663XuD35UVuOyIf3Zld0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H6jRZJTO; 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="H6jRZJTO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74136C2BCB1; Wed, 11 Mar 2026 05:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773206971; bh=aGbllmaaq9J7Qd8uyVbLEXseWZd1bfmXTBQJFAjpS5A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H6jRZJTOTU4p8b7NVG4ikk3Ufgt08EDESkq6teQ6x1piVHyuyBVy12Jopkr+JSBGR 4QUIxeZEbR1zhDZfR1KhtbTeL3gf30/ZXNRFyk61is+06IVPMMWhC7Fhyq6F1O0jVL IHst+/bFywOsmwXmA0cs8u/XEiuhDmxyA3IGoLLMzepARhSRFOpaBDsmyIH9D2L8lK CHZa5Y+Ntg2/gMQnRZE02bO707dvqaOEn6h0eYz0ekCsSa5pq6P/DAfNbleTESFid8 rTZ0po2uJjVdzTKF920YK1wkXR9dZgugdCkA7WDDvQcNGBfHKIPBpqGJ3eM0rWR+XH 89NfYufvRjUCg== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 2/5] mm/damon/core: support addr_unit on damon_find_biggest_system_ram() Date: Tue, 10 Mar 2026 22:29:23 -0700 Message-ID: <20260311052927.93921-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260311052927.93921-1-sj@kernel.org> References: <20260311052927.93921-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 3925720a172a6..aee61bf991baa 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3056,31 +3056,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 @@ -3110,7 +3123,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 Wed Apr 8 02:54:44 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 DC5A8333447; Wed, 11 Mar 2026 05:29:31 +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=1773206971; cv=none; b=p2TD+NbDwmz20hE4ta91DXjczWtaZ5fE34RmiQgY7dI6Ty4DZuhvi2gNnBVxKXdS9bB8gk8eFKWFg+bhsolEXoWD8YxGhPuIeWqse2qbQtXe9EqaTS/gOLZbhCeWRckvwHRAcTa9nHpmt/cyyI7Sw7WW7fhq0QwuIu9oUtOcPtk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773206971; c=relaxed/simple; bh=kid8+DV+15MxZOJX+3t1IGU6wUDJNNJXItme1YWcb1M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vGIyCakQqxMXyJ2eOtUPTFf4Q8zYpdUFboCjyuJ4rwXnGrTPJIaleOUFCJP1akPgiDgmKSbiweVx6PEe0B9M/ASDJZ7ETT65HKgK/Ar8VgAymnsDUlcHQDPNYBMRJTzE/+F7zKRSMrcaKkVo99Q0qXFwmYryoJBJ1odDG9KsgRk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MHV8bgoP; 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="MHV8bgoP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A83E2C2BCB2; Wed, 11 Mar 2026 05:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773206971; bh=kid8+DV+15MxZOJX+3t1IGU6wUDJNNJXItme1YWcb1M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MHV8bgoPLGkg/C+8Std46vK90hCsqe8haO2pX/KRjAmTqvPnjiHvIPENmLmfScqRW yE/6CpcuHS+fcq374PZqPPtCsTZbuix9yONjFn9id8mMxZEOfacWjRTijwvVKAOU6Y epb2/JASZSGFYXXHQoYT4v9OoN5EqTSM9Zd8CGFlC2TLllKqGgh/8wFG+kSJZs78rN YwG8NDS+Ly8pNlHkWiqq47Lr6Ws7xHNuRjH7PkJObMnuZHidizHI9ek2HK5kS3QMoF 7YPyyS0yBSnpn4t6rrwpPjeXPhMBQCflKrBvIeccLpBV260wtqN3PX5Wh4s5wu8xU3 dEAJGf+bWzk3g== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 3/5] mm/damon/core: receive addr_unit on damon_set_region_biggest_system_ram_default() Date: Tue, 10 Mar 2026 22:29:24 -0700 Message-ID: <20260311052927.93921-4-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260311052927.93921-1-sj@kernel.org> References: <20260311052927.93921-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 more reason to not support addr_unit on damon_set_region_biggest_system_ram_default(). Rather, it makes unnecessary inconsistency on support of addr_unit. Update it to receive addr_unit and handle it inside. 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 1130c2f9a92f4..3a441fbca170d 100644 --- a/include/linux/damon.h +++ b/include/linux/damon.h @@ -988,6 +988,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 aee61bf991baa..d4f86c20b4f48 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3103,6 +3103,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 @@ -3115,7 +3116,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 @@ -3123,12 +3124,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 Wed Apr 8 02:54:44 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 3474F337B99; Wed, 11 Mar 2026 05:29:32 +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=1773206972; cv=none; b=anu8+HbeQy96FAujS8mzNShPCYSLOeGI2XM79NSyKKUh62iIPM9MyK1w4a1RFHwHUJIXlPgdfrssuVeeoDwo1Xx8jOjA7k3LoS8pvh438uJYuUQ8Hj+/PJfGnodipWCwT86j4PkEbeVbFUlSrejFwTQOt8ywW3N1tkltR4Ze+DM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773206972; c=relaxed/simple; bh=N3PMziG0nx7W5Sw5jivaZWpK/XVFOxMsVgwXy8jopsI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OVWs6xQt6ckh2jSmR658DGN/DTGW4QRLTpd9hpa0jXj0himv6Eh7VGHPJmA5YOpWWHftUkDX4VAX4bvmGkk2f3IPubxAPyr/Z1dNkJWDjUp7mcANbSVC+5S2nvtRJfDFVaUROH4SQlhVCGAcYFDDtbJSKUebOK8jqR0qTXTYdw4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d9jXiOPm; 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="d9jXiOPm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC00AC2BC9E; Wed, 11 Mar 2026 05:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773206972; bh=N3PMziG0nx7W5Sw5jivaZWpK/XVFOxMsVgwXy8jopsI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d9jXiOPmvvWD9+75USBmaiUljjf15lswFDs+RYX2I5WR6ie15weaESToBTDnYeynM twPYsp0Q6NacG2pgCIDbVMDJp4xG2WO5ixUgiNK6K0x4IIgY0g4ThG7RkIdJVT3Eeq l81dkg9efoFCzT2i68P9sbwPbWDKyRE6xrrvrixq8CcdxMUYgQRVFPLkiv8GC3nNu9 Ex7FQOuyI5sPLUwu2hLKN0wsoUnkT9tnnWaIJSFHrbFJiArOVumWbgM2AL5AbgOWrT cwVdKEZeXV2yxPVC/tKiI9guFeGLIxGMuN8c8F2k2tgJJdNh+5lcVyRqpOjxrj4if7 eRUNkd4Q6ua9w== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 4/5] mm/damon/reclaim: respect addr_unit on default monitoring region setup Date: Tue, 10 Mar 2026 22:29:25 -0700 Message-ID: <20260311052927.93921-5-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260311052927.93921-1-sj@kernel.org> References: <20260311052927.93921-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 the user input for addr_unit when the user doesn't explicitly set the monitoring target regions, and therefore the default target region is being used. No real problem from that ignorance was reported so far. But, the implicit rule is only making things confusing. Also, the default target region setup function is updated to support addr_unit. Hence there is no reason to keep ignoring it. Respect the user-passed 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 Wed Apr 8 02:54:44 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 75D7133D503; Wed, 11 Mar 2026 05:29:32 +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=1773206972; cv=none; b=mzKoPUTruR0b94ldVxxQiiOFcFF+GTYMcbHQP0Qwvbn8vpudyBzjxa7sTMoF+FAxlqbuqR6IXScUrmRg6uzHWAPOVnO9GkVO65Fk20b0cVn8yWE8JTRx3ItA87BgDTyAfi3iRhHVEnh927I5cLUwARo7ttYGnrxshI/FC1a5JFA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773206972; c=relaxed/simple; bh=ESvZf4UkUBS6SSFEGCLnD8WnAsHOvLPTsDE9mnF1u0Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MXJ9YrpNf+iuFjmuwYDcRKyS5sOAYsqMa1sCzIYEhzHilAkBbjoauUqm7kMxBUGjbHX0n0PCVG5+1Z+gOUNwmN8vlrcJIwkP3+7m/dEF5LECO3LvMTWUCy5VYYQ15nvr9+zOfCUtDSznI2KQedFYjcjZXsR6DmRrFR5aaoki2TQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RUFZR4CD; 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="RUFZR4CD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B3B9C19425; Wed, 11 Mar 2026 05:29:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773206972; bh=ESvZf4UkUBS6SSFEGCLnD8WnAsHOvLPTsDE9mnF1u0Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RUFZR4CDVcc+9x4268CeSuiPQAG7y6RnDcoFnSLsGZUpeyOlKbFXFR57tXoUAc2Pz MuyXRVn698cI6fITK9reHO5e0sjhJzUrk5FvfdQ47VdrcLkn5lQLSHt2R954aGQCVP tnkYnn7+hYO3K1C+qNX7KkQDIhMPc9eEHdwQbOXQee2BJkDBoenu/6/vfUsW5bHIP8 +dJJMg8up4CPyIqSXPrEwm3voEah2VnWzmB+HYdboVkdY+xwYo0q+umhxbQjpyXl1x nw1r0XKO0aso+lFc7m6N4okCw+Gjer4L/UsDsLL4zfCM8UITryigJQrAEYZ7Jphb+J Fjahs/sBzuY0w== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 5/5] mm/damon/lru_sort: respect addr_unit on default monitoring region setup Date: Tue, 10 Mar 2026 22:29:26 -0700 Message-ID: <20260311052927.93921-6-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260311052927.93921-1-sj@kernel.org> References: <20260311052927.93921-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 the user input for addr_unit when the user doesn't explicitly set the monitoring target regions, and therefore the default target region is being used. No real problem from that ignorance was reported so far. But, the implicit rule is only making things confusing. Also, the default target region setup function is updated to support addr_unit. Hence there is no reason to keep ignoring it. Respect the user-passed 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