Re: [RFC PATCH] mm/damon: introduce damos_sort_type for re-ordering regions list

Re: [RFC PATCH] mm/damon: introduce damos_sort_type for re-ordering regions list

[SJ Park]

Hello Liew,


Thank you for sharing this patch.

On Tue,  4 Aug 2026 18:07:19 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Problem
> =======
> 
> A DAMOS scheme filters its target regions using an access pattern, which
> is constructed with the size, the access frequency (nr_accesses), and
> the age of the regions. The age here means how long the current access
> pattern of a region has been maintained.
> 
> For the pageout action, the age.min of the access pattern effectively
> acts as the minimum amount of time that the target regions must have been
> unused.
> 
> The definition of cold memory highly depends on the devices and
> workloads, and thus setting a proper default age.min (e.g., min_age of
> DAMON_RECLAIM) is both important and nearly impossible to make suitable
> for all devices and workloads.

The recommended way is setting the min_age naive, and auto-tune it using DAMOS
quota or aim-oriented quota auto-tuning.  Have you considered using that?

> 
> Solution
> ========
> 
> Add a per-scheme sysfs attribute, schemes/<N>/sort_type, whose default
> value is 'none'. A scheme can set it to 'score_desc', which makes the
> scheme to collect the target regions and apply its action in descending
> order of the regions' scores, as calculated by the ops.get_scheme_score()
> callback, during the application. For a pageout scheme, the callback
> returns the coldness score of each region.
> 
> Instead of modifying the region list, DAMON copies the target valid
> regions into a temporary array, sorts the array in descending order of
> the regions' scores, and applies the action in the sorted order.
> 
> With this, the scheme gives absolute priority to the highest-scored
> region. For example, a pageout scheme with 'score_desc' reclaims the
> coldest region of the target first. Users can thus keep the age.min
> relatively small and let the score ordering do the precise
> prioritization.
> 
> Note that regions are applied in the score order, not the address order.
> Therefore, the address-based quota charge resume mechanism is not
> available for such schemes. Instead, the quota is spent on the
> highest-scored regions of each charge window. Applying an action
> resets the age of the applied regions (except for 'stat' action), so
> those regions are naturally excluded from the next window if the scheme
> has a non-zero age.min. Also, when a region is split for the quota, the
> age of the split-out part is preserved, and thus the highest-scored
> region is continuously applied until it is fully reclaimed, even when it
> is larger than the remaining quota of a single window.

This sounds like very similar to DAMOS quota's regions prioritizing mechanism.
Have you considered using DAMOS quota?  If so, could you please add why
proposing this new mechanism, with some comparisons?

> 
> Signed-off-by: Liew Rui Yan <aethernet65535@gmail.com>
> ---
> I am currently running the corresponding benchmarks to ensure that this
> does not introduce too much performance overhead, at least not on my
> device.
> 
> The purpose of sending this patch is to make sure this is a right
> direction.
> 
> About my device/VM
> ==================
> 
> CPU: AMD Ryzen 5 5600H (12 Cores)
> RAM: 8GiB in VM (4GiB + 4GiB ZRAM)
> 
> I currently foresee two potential issues with thiss patch, though I
> have not obtained the test results yet, so these are just guesses.
> 
> 1. Excessive memory allocations and deallocations 
> 
>     The default aggr_interval is 100ms. Executing at least one
>     allocation and deallocation every 100ms is very likely to cause
>     unnecessary performance overhead.
> 
>     I think this issue could be resolved by having the scheme maintain
>     its own buffer.
> 
> 2. Performance overhead of re-ordering
> 
>     Although on my device the number of regions is not very large, and
>     DAMON's default limit of 1,000 regions also helps avoid performance
>     overhead, I suspect that large servers might not stick to just 1,000
>     regions.
> 
>     A solution I can think of is using a Top K Min Heap, though that
>     might significantly increase code complexity and reduce readability.

I'm indeed concerned about this.

> 
> As a reminder, these are just my __guesses__ and do not necessarily
> reflect what will happen in practice. I will send another email after
> completing the benchmarks and micro-performance testing.
> 
>  include/linux/damon.h    |   6 ++
>  mm/damon/core.c          | 125 ++++++++++++++++++++++++++++++++++++++-
>  mm/damon/sysfs-schemes.c |  57 ++++++++++++++++++
>  3 files changed, 187 insertions(+), 1 deletion(-)

I to be honest feel this is too much for "just guess" based patch.  I'd like to
get clear reasoning of the change and/or test results before reviewing the
code.  So I'm holding the code review until the high level discussion is done.


Thanks,
SJ

[...]

Re: [RFC PATCH] mm/damon: introduce damos_sort_type for re-ordering regions list

[Liew Rui Yan]

Hi SJ,

First of all, I apologize for the noise, and I will drop this patch.
Secondly, thank you for pointing this out, it made me realize that I was
fixing a non-existent problem.

On Tue,  4 Aug 2026 06:58:33 -0700 SJ Park <sj@kernel.org> wrote:

> The recommended way is setting the min_age naive, and auto-tune it using DAMOS
> quota or aim-oriented quota auto-tuning.  Have you considered using that?

> This sounds like very similar to DAMOS quota's regions prioritizing mechanism.
> Have you considered using DAMOS quota?  If so, could you please add why
> proposing this new mechanism, with some comparisons?

Yes, I have. And you are right; the existing mechanism is better. I
wrote this patch because I misunderstood quota.min_score and did not
even check the implementation of damos_adjust_quota().

Whether when implementing dama [1] or this damos_sort_type, I failed to
realize that min_age might not be such an important parameter on a
long-running system, and there is really no need to introduce
auto-tuning or a new mechanism for it.

> I to be honest feel this is too much for "just guess" based patch.  I'd like to
> get clear reasoning of the change and/or test results before reviewing the
> code.  So I'm holding the code review until the high level discussion is done.

Moving forward, I will ensure I am not "reinventing the wheel" or
"fixing non-existent problem".

Thank you again for pointing this out. In the future contributions, I
will try my best to avoid spending time fixing problems that do not
actually exist.

[1] https://lore.kernel.org/damon/20260628085155.20828-1-aethernet65535@gmail.com

Best regards,
Rui Yan

Re: [RFC PATCH] mm/damon: introduce damos_sort_type for re-ordering regions list

[SJ Park]

On Wed,  5 Aug 2026 16:12:46 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Hi SJ,
> 
> First of all, I apologize for the noise, and I will drop this patch.
> Secondly, thank you for pointing this out, it made me realize that I was
> fixing a non-existent problem.

No worry, it was good to discuss the idea together!

> 
> On Tue,  4 Aug 2026 06:58:33 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > The recommended way is setting the min_age naive, and auto-tune it using DAMOS
> > quota or aim-oriented quota auto-tuning.  Have you considered using that?
> 
> > This sounds like very similar to DAMOS quota's regions prioritizing mechanism.
> > Have you considered using DAMOS quota?  If so, could you please add why
> > proposing this new mechanism, with some comparisons?
> 
> Yes, I have. And you are right; the existing mechanism is better. I
> wrote this patch because I misunderstood quota.min_score and did not
> even check the implementation of damos_adjust_quota().

Thank you for transparently clarifying these details, Liew.  This is very
helpful at conversations.

> 
> Whether when implementing dama [1] or this damos_sort_type, I failed to
> realize that min_age might not be such an important parameter on a
> long-running system, and there is really no need to introduce
> auto-tuning or a new mechanism for it.
> 
> > I to be honest feel this is too much for "just guess" based patch.  I'd like to
> > get clear reasoning of the change and/or test results before reviewing the
> > code.  So I'm holding the code review until the high level discussion is done.
> 
> Moving forward, I will ensure I am not "reinventing the wheel" or
> "fixing non-existent problem".

I appreciate that.  That will be super helpful.  But I understand we are human
that cannot "ensure" everything always.  Please try not to spend too much time
on unnecessary thing.  But don't be scared at making some mistakes, because we
learn from mistakes.

> 
> Thank you again for pointing this out. In the future contributions, I
> will try my best to avoid spending time fixing problems that do not
> actually exist.

Sounds nice.  And feel free to ask questions or help.

> 
> [1] https://lore.kernel.org/damon/20260628085155.20828-1-aethernet65535@gmail.com


Thanks,
SJ

[...]