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

[SJ Park <sj@kernel.org>]

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

[...]