Re: [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE.

[SeongJae Park <sj@kernel.org>]

On Tue, 24 Mar 2026 18:01:23 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 3/24/2026 5:12 PM, SeongJae Park wrote:
> > On Tue, 24 Mar 2026 16:57:22 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
> > 
> >>
> >>
> >> On 3/24/2026 3:39 AM, SeongJae Park wrote:
> >>> Hello Asier,
> >>>
> >>> On Mon, 23 Mar 2026 14:56:45 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> >>>
> >>>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >>>>
> >>>> For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
> >>>> working, since it relies on hugepage_madvise to add a new slot. This
> >>>> slot should be picked up by khugepaged and eventually collapse (or
> >>>> not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
> >>>> enabled, khugepaged will not be working, and therefore no collapse
> >>>> will happen.
> >>>>
> >>>> DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
> >>>> the address range synchronously.
> >>>>
> >>>> This new action may be required to support autotuning with hugepage as
> >>>> a goal[1].
> >>>>
> >>>> [1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
> >>>>
> >>>> ---------
> >>>> Benchmarks:
> >>>>
> >>>> T n: THP never
> >>>> T m: THP madvise
> >>>> D h: DAMON action hugepage
> >>>> D c: DAMON action collapse
> >>>>
> >>>> +------------------+----------+----------+----------+
> >>>> |                  | T n, D h | T m, D h | T n, D c |
> >>>> +------------------+----------+----------+----------+
> >>>> | Total memory use | 2.07     | 2.09     | 2.07     |
> >>>> | Huge pages       | 0        | 1.3      | 1.25     |
> >>>> +------------------+----------+----------+----------+
> >>>
> >>> Thank you for sharing the benchmark results!  But, I'm having a hard time to
> >>> understand what this really means.  Could you please further clarify the setup
> >>> of the benchmarks and interpretation of the results?
> >> I will fix the cover in the next version, which I will submit soon.
> >>
> >> I tested the patch in a physical server with MariaDB 10.5. I run
> >> sysbench to load the server.
> >>
> >> I check 3 scenarios:
> >> - DAMON action hugepage for the database task, THP as never
> >> - DAMON action hugepage, THP madvise
> >> - DAMON action collapse, THP never
> >>
> >> I compared the memory consumption, both in overall in the server and
> >> anonymous huge page consumption. The results are in the table
> >>
> >> T n: THP never
> >> T m: THP madvise
> >> D h: DAMON action hugepage
> >> D c: DAMON action collapse
> > 
> > Thank you for sharing the details of the setup, Asier.
> > 
> >>
> >> +------------------+----------+----------+----------+
> >> |                  | T n, D h | T m, D h | T n, D c |
> >> +------------------+----------+----------+----------+
> >> | Total memory use | 2.07     | 2.09     | 2.07     |
> >> | Huge pages       | 0        | 1.3      | 1.25     |
> >> +------------------+----------+----------+----------+
> > 
> > Could you please further share interpretation of the results?  What these
> > results mean?  Does it show some benefit of DAMOS_COLLAPSE?
> 
> In the first row is the total memory consumption in GB by the server
> and in the second row the huge page consumption.
> 
> What this table shows is that DAMON action "hugepage" doesn't lead
> to any hugepage collapse unless THP is set to madvise. If DAMON
> action is set to "collapse", hugepage collapses happen, even when
> THP is disabled. The memory consumption for DAMON "collapse" is
> slightly lower than with "hugepage", since madvise applies to the
> entire server and other application may request to collapse pages
> through madvise.
> 
> Regarding the performance, I saw improvement from no hugepage at all
> to use of hugepages. No significant difference between "hugepage" and 
> "collapse" actions. I will have a look to the logs and publish it a bit
> later.

Makes sense, thank you for clarification Asier!

So this result shows the functionality well.  Meanwhile, it doesn't clearly
show performance gain.  Given the small size of the change and rationale of
MADV_COLLAPSE that I believe explored when it was introduced, I think this test
result is also good.  I wouldn't strongly require more tests for this patch.

That said, if you find some more interesting thing from logs, please share, by
or after the next version of this patch.


Thanks,
SJ

[...]