* [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix
@ 2024-07-16 18:33 SeongJae Park
2024-07-16 18:33 ` [PATCH 5.15.y 8/8] mm/damon/core: merge regions aggressively when max_nr_regions is unmet SeongJae Park
2024-07-23 12:15 ` [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix Greg KH
0 siblings, 2 replies; 4+ messages in thread
From: SeongJae Park @ 2024-07-16 18:33 UTC (permalink / raw)
To: stable, gregkh
Cc: SeongJae Park, Andrew Morton, Ingo Molnar, Luc Van Oostenryck,
Steven Rostedt, damon, linux-mm, linux-sparse, linux-kernel
Commit 310d6c15e910 ("mm/damon/core: merge regions aggressively when
max_nr_regions") causes a build warning and a build failure [1] on
5.15.y. Those are due to
1) unnecessarily strict type check from max(), and
2) use of not-yet-introduced damon_ctx->attrs field, respectively.
Fix the warning by backporting a minmax.h upstream commit that made the
type check less strict for unnecessary case, and upstream commits that
it depends on.
Note that all patches except the fourth one ("minmax: fix header
inclusions") are clean cherry-picks of upstream commit. For the fourth
one, minor conflict resolving was needed.
Also, the last patch, which is the backport of the DAMON fix, was
cleanly cherry-picked, but added manual fix for the build failure.
[1] https://lore.kernel.org/2024071532-pebble-jailhouse-48b2@gregkh
Andy Shevchenko (1):
minmax: fix header inclusions
Bart Van Assche (1):
tracing: Define the is_signed_type() macro once
David Laight (3):
minmax: allow min()/max()/clamp() if the arguments have the same
signedness.
minmax: allow comparisons of 'int' against 'unsigned char/short'
minmax: relax check to allow comparison between unsigned arguments and
signed constants
Jason A. Donenfeld (2):
minmax: sanity check constant bounds when clamping
minmax: clamp more efficiently by avoiding extra comparison
SeongJae Park (1):
mm/damon/core: merge regions aggressively when max_nr_regions is unmet
include/linux/compiler.h | 6 +++
include/linux/minmax.h | 89 ++++++++++++++++++++++++++----------
include/linux/overflow.h | 1 -
include/linux/trace_events.h | 2 -
mm/damon/core.c | 23 ++++++++--
5 files changed, 90 insertions(+), 31 deletions(-)
base-commit: 4d1b7f1bf3858ed48a98c004bda5fdff2cdf13c8
--
2.39.2
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH 5.15.y 8/8] mm/damon/core: merge regions aggressively when max_nr_regions is unmet 2024-07-16 18:33 [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix SeongJae Park @ 2024-07-16 18:33 ` SeongJae Park 2024-07-23 12:15 ` Patch "mm/damon/core: merge regions aggressively when max_nr_regions is unmet" has been added to the 5.15-stable tree gregkh 2024-07-23 12:15 ` [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix Greg KH 1 sibling, 1 reply; 4+ messages in thread From: SeongJae Park @ 2024-07-16 18:33 UTC (permalink / raw) To: stable, gregkh Cc: SeongJae Park, Andrew Morton, damon, linux-mm, linux-kernel commit 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6 upstream. DAMON keeps the number of regions under max_nr_regions by skipping regions split operations when doing so can make the number higher than the limit. It works well for preventing violation of the limit. But, if somehow the violation happens, it cannot recovery well depending on the situation. In detail, if the real number of regions having different access pattern is higher than the limit, the mechanism cannot reduce the number below the limit. In such a case, the system could suffer from high monitoring overhead of DAMON. The violation can actually happen. For an example, the user could reduce max_nr_regions while DAMON is running, to be lower than the current number of regions. Fix the problem by repeating the merge operations with increasing aggressiveness in kdamond_merge_regions() for the case, until the limit is met. [sj@kernel.org: increase regions merge aggressiveness while respecting min_nr_regions] Link: https://lkml.kernel.org/r/20240626164753.46270-1-sj@kernel.org [sj@kernel.org: ensure max threshold attempt for max_nr_regions violation] Link: https://lkml.kernel.org/r/20240627163153.75969-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240624175814.89611-1-sj@kernel.org Fixes: b9a6ac4e4ede ("mm/damon: adaptively adjust regions") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [5.15+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6) Signed-off-by: SeongJae Park <sj@kernel.org> [Remove use of unexisting damon_ctx->attrs field] --- mm/damon/core.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 7a4912d6e65f..4f031412f65c 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -507,14 +507,31 @@ static void damon_merge_regions_of(struct damon_target *t, unsigned int thres, * access frequencies are similar. This is for minimizing the monitoring * overhead under the dynamically changeable access pattern. If a merge was * unnecessarily made, later 'kdamond_split_regions()' will revert it. + * + * The total number of regions could be higher than the user-defined limit, + * max_nr_regions for some cases. For example, the user can update + * max_nr_regions to a number that lower than the current number of regions + * while DAMON is running. For such a case, repeat merging until the limit is + * met while increasing @threshold up to possible maximum level. */ static void kdamond_merge_regions(struct damon_ctx *c, unsigned int threshold, unsigned long sz_limit) { struct damon_target *t; - - damon_for_each_target(t, c) - damon_merge_regions_of(t, threshold, sz_limit); + unsigned int nr_regions; + unsigned int max_thres; + + max_thres = c->aggr_interval / + (c->sample_interval ? c->sample_interval : 1); + do { + nr_regions = 0; + damon_for_each_target(t, c) { + damon_merge_regions_of(t, threshold, sz_limit); + nr_regions += damon_nr_regions(t); + } + threshold = max(1, threshold * 2); + } while (nr_regions > c->max_nr_regions && + threshold / 2 < max_thres); } /* -- 2.39.2 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Patch "mm/damon/core: merge regions aggressively when max_nr_regions is unmet" has been added to the 5.15-stable tree 2024-07-16 18:33 ` [PATCH 5.15.y 8/8] mm/damon/core: merge regions aggressively when max_nr_regions is unmet SeongJae Park @ 2024-07-23 12:15 ` gregkh 0 siblings, 0 replies; 4+ messages in thread From: gregkh @ 2024-07-23 12:15 UTC (permalink / raw) To: akpm, damon, gregkh, linux-mm, sj; +Cc: stable-commits This is a note to let you know that I've just added the patch titled mm/damon/core: merge regions aggressively when max_nr_regions is unmet to the 5.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: mm-damon-core-merge-regions-aggressively-when-max_nr_regions-is-unmet.patch and it can be found in the queue-5.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@vger.kernel.org> know about it. From sj@kernel.org Tue Jul 16 20:33:48 2024 From: SeongJae Park <sj@kernel.org> Date: Tue, 16 Jul 2024 11:33:33 -0700 Subject: mm/damon/core: merge regions aggressively when max_nr_regions is unmet To: stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: SeongJae Park <sj@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Message-ID: <20240716183333.138498-9-sj@kernel.org> From: SeongJae Park <sj@kernel.org> commit 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6 upstream. DAMON keeps the number of regions under max_nr_regions by skipping regions split operations when doing so can make the number higher than the limit. It works well for preventing violation of the limit. But, if somehow the violation happens, it cannot recovery well depending on the situation. In detail, if the real number of regions having different access pattern is higher than the limit, the mechanism cannot reduce the number below the limit. In such a case, the system could suffer from high monitoring overhead of DAMON. The violation can actually happen. For an example, the user could reduce max_nr_regions while DAMON is running, to be lower than the current number of regions. Fix the problem by repeating the merge operations with increasing aggressiveness in kdamond_merge_regions() for the case, until the limit is met. [sj@kernel.org: increase regions merge aggressiveness while respecting min_nr_regions] Link: https://lkml.kernel.org/r/20240626164753.46270-1-sj@kernel.org [sj@kernel.org: ensure max threshold attempt for max_nr_regions violation] Link: https://lkml.kernel.org/r/20240627163153.75969-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240624175814.89611-1-sj@kernel.org Fixes: b9a6ac4e4ede ("mm/damon: adaptively adjust regions") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [5.15+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit 310d6c15e9104c99d5d9d0ff8e5383a79da7d5e6) Signed-off-by: SeongJae Park <sj@kernel.org> [Remove use of unexisting damon_ctx->attrs field] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- mm/damon/core.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -507,14 +507,31 @@ static void damon_merge_regions_of(struc * access frequencies are similar. This is for minimizing the monitoring * overhead under the dynamically changeable access pattern. If a merge was * unnecessarily made, later 'kdamond_split_regions()' will revert it. + * + * The total number of regions could be higher than the user-defined limit, + * max_nr_regions for some cases. For example, the user can update + * max_nr_regions to a number that lower than the current number of regions + * while DAMON is running. For such a case, repeat merging until the limit is + * met while increasing @threshold up to possible maximum level. */ static void kdamond_merge_regions(struct damon_ctx *c, unsigned int threshold, unsigned long sz_limit) { struct damon_target *t; + unsigned int nr_regions; + unsigned int max_thres; - damon_for_each_target(t, c) - damon_merge_regions_of(t, threshold, sz_limit); + max_thres = c->aggr_interval / + (c->sample_interval ? c->sample_interval : 1); + do { + nr_regions = 0; + damon_for_each_target(t, c) { + damon_merge_regions_of(t, threshold, sz_limit); + nr_regions += damon_nr_regions(t); + } + threshold = max(1, threshold * 2); + } while (nr_regions > c->max_nr_regions && + threshold / 2 < max_thres); } /* Patches currently in stable-queue which might be from sj@kernel.org are queue-5.15/minmax-allow-min-max-clamp-if-the-arguments-have-the-same-signedness.patch queue-5.15/minmax-sanity-check-constant-bounds-when-clamping.patch queue-5.15/minmax-clamp-more-efficiently-by-avoiding-extra-comparison.patch queue-5.15/minmax-relax-check-to-allow-comparison-between-unsigned-arguments-and-signed-constants.patch queue-5.15/minmax-fix-header-inclusions.patch queue-5.15/mm-damon-core-merge-regions-aggressively-when-max_nr_regions-is-unmet.patch queue-5.15/tracing-define-the-is_signed_type-macro-once.patch queue-5.15/minmax-allow-comparisons-of-int-against-unsigned-char-short.patch ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix 2024-07-16 18:33 [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix SeongJae Park 2024-07-16 18:33 ` [PATCH 5.15.y 8/8] mm/damon/core: merge regions aggressively when max_nr_regions is unmet SeongJae Park @ 2024-07-23 12:15 ` Greg KH 1 sibling, 0 replies; 4+ messages in thread From: Greg KH @ 2024-07-23 12:15 UTC (permalink / raw) To: SeongJae Park Cc: stable, Andrew Morton, Ingo Molnar, Luc Van Oostenryck, Steven Rostedt, damon, linux-mm, linux-sparse, linux-kernel On Tue, Jul 16, 2024 at 11:33:25AM -0700, SeongJae Park wrote: > Commit 310d6c15e910 ("mm/damon/core: merge regions aggressively when > max_nr_regions") causes a build warning and a build failure [1] on > 5.15.y. Those are due to > 1) unnecessarily strict type check from max(), and > 2) use of not-yet-introduced damon_ctx->attrs field, respectively. > > Fix the warning by backporting a minmax.h upstream commit that made the > type check less strict for unnecessary case, and upstream commits that > it depends on. > > Note that all patches except the fourth one ("minmax: fix header > inclusions") are clean cherry-picks of upstream commit. For the fourth > one, minor conflict resolving was needed. > > Also, the last patch, which is the backport of the DAMON fix, was > cleanly cherry-picked, but added manual fix for the build failure. > > [1] https://lore.kernel.org/2024071532-pebble-jailhouse-48b2@gregkh All now queued up, again, thank you for the minmax backports, much appreciated. greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-07-23 12:16 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-07-16 18:33 [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix SeongJae Park 2024-07-16 18:33 ` [PATCH 5.15.y 8/8] mm/damon/core: merge regions aggressively when max_nr_regions is unmet SeongJae Park 2024-07-23 12:15 ` Patch "mm/damon/core: merge regions aggressively when max_nr_regions is unmet" has been added to the 5.15-stable tree gregkh 2024-07-23 12:15 ` [PATCH 5.15.y 0/8] Backport patches for DAMON merge regions fix Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).