Re: [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

[SJ Park <sj@kernel.org>]

On Wed, 8 Jul 2026 17:50:57 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> Hi SJ,
> 
> On 7/8/2026 4:22 AM, SJ Park wrote:
> > On Tue, 7 Jul 2026 17:25:36 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
[...]
> >> I have no idea, to be honest. I will try to test with different databasesizes with temporal and consistent policies. The behaviour was weird to me,
> >> but I don't know if this was a TEMPORAL policy issue or I didn't set the
> >> DAMON parameters correctly.
> > 
> > Thank you for transparently sharing your thought.  And this is little bit
> > concerning me.  It feels like we don't really have a good theory about what
> > change will make what results for what reason.  It rather feels like we just
> > doing random experiments and showing the random results.
> > 
> > I understand having data first and developing the theory driven by data is also
> > a good approach.  But I feel like this is a time to step back and think about
> > what we're doing.
> > 
> > IIRC, your initial experiment results on the very early version of this series
> > looked promising.  But from a point, it looked like just random.  Maybe I gave
> > you wrong change request, or some test environment has unexpectedly changed.
> > 
> > How about summarizing what tests you did so far, what changes in the kernel and
> > the test setup has made for each iteration, and how the results have changed?
> > 
> > If it has been too long since the older tests, just doing the tests again or
> > dive deep into debugging of your current setup with the all mighty printk() on
> > core DAMON internall code can be an option.
> > 
> > Have you also monitored DAMOS stats while the tests are ongoing?  Maybe that
> > could also be a good debugging option for understanding what's going on as
> > expected vs not.
> The problem I've been having is inconsistent results. This may be due to thefact that I'm testing primarily with database, which contains a lot of
> variable data, like indexes that may be hit sometimes, and other times not,
> different data distribution, etc.

Makes sense.  Testing is another challenging area of arts.

If you find it is too difficult to have a stable test setup, I wouldn't mind
using more artificial test setup for test results on this series' cover letter.
I'd request it to be only makes sense and shows a sane and complete story.

It would be really great if you can apply this on more realistic environments
and share the wins.  But that's not necessarily a blocker of this series in my
opinion.

> 
> I've been trying to get a test as consistent as possible, pinning the
> database to a single NUMA node and the tests script to another one, avoid
> network traffic, etc.
> 
> I am almost done getting some consistent data.

Cool.

> 
> Maybe I can use perf to get DAMOS tracing. Would that make it?

Yes, that should work.

'damo' also provides a wrapper of 'perf' for tracing purpose.  If you want to
try it, I'd suggest something like below:

    damo report trace --event damon:damos_esz damon:damos_stat_after_apply_interval

[...]
> Thanks to you. I will keep testing and keep you posted in the coming days.

You're welcome.  No rush.  Take your time and fun :)


Thanks,
SJ

[...]