On Wed, 26 Jun 2024 14:49:54 -0700 SeongJae Park <sj@xxxxxxxxxx> wrote: > > @@ -1716,8 +1717,8 @@ static void kdamond_merge_regions(struct damon_ctx *c, unsigned int threshold, > > nr_regions += damon_nr_regions(t); > > } > > threshold = max(1, threshold * 2); > > - sz_limit = max(1, sz_limit * 2); > > - } while (nr_regions > c->attrs.max_nr_regions); > > + } while (nr_regions > c->attrs.max_nr_regions && > > + threshold <= max_thres); > > This code means that kdamond_merge_regions() stops this repeated merge attempt > if the merge threshold that increased for next attempt is higher than the > possible maximum threshold. And because the increase of the threshold is made > by picking a maximum value between one and the last-used threshold multiplying > two, the merge attempt with maximum threshold will not be made unless both the > maximum threshold and the threshold to increase are powers of two. In maximum > situation (e.g., region 1 has 100% access frequency, region 2 has 0% access > frequency, so on), this means the max_nr_regions violation cannot be recovered > by the attempts. > > This can be fixed by changing it to stop repeated attempt if the last-used > threshold is same to or higher than the maximum possible threshold, like below. > > I'll send the fix of the fix as a formal patch soon. > > FYI, the original fix is definitely better to be merged in stable kernels, but > not urgent in my opinion, since the problematic case is not common and the > behavior was same since the beginning of DAMON. Andrew, if you feel the > original fix is not stable yet, please feel free to delay moving it to > hotfix-stable for one week or two. That's fine - we can merge cc:stable patches any time, really - they will still get backported. There's only a hurry to get fixes merged up if they're security-related or if the issue is causing people problems. In this case I'll await your -fix-2.patch and we can merge the patch next week.
