From: SJ Park <sj@kernel.org>
To: Gutierrez Asier <gutierrez.asier@huawei-partners.com>
Cc: SJ Park <sj@kernel.org>,
artem.kuzin@huawei.com, stepanov.anatoly@huawei.com,
wangkefeng.wang@huawei.com, yanquanmin1@huawei.com,
zuoze1@huawei.com, damon@lists.linux.dev,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning
Date: Mon, 13 Jul 2026 07:45:12 -0700 [thread overview]
Message-ID: <20260713144513.39596-1-sj@kernel.org> (raw)
In-Reply-To: <03f678dd-9ef3-4b97-b753-c2e4554c5159@huawei-partners.com>
On Mon, 13 Jul 2026 14:30:40 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
> Hi SJ,
>
> On 7/6/2026 6:16 PM, SJ Park wrote:
> > On Mon, 6 Jul 2026 18:03:03 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
> >
> >> Hi SJ,
> >>
> >> On 6/20/2026 8:11 PM, Gutierrez Asier wrote:
> >>> Hi SJ,
> >>>
> >>> So sorry, I missed your email. I just found it. Sorry for the late answer.
> >>>
> >>> On 6/17/2026 4:44 AM, SeongJae Park wrote:
> >>>> On Tue, 16 Jun 2026 15:03:13 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> >>>>
> >>>>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >>>>>
> >>>>> Overview
> >>>>> ========
> >>>>>
> >>>>> This patch set introduces a new autotuning which allows to collapse
> >>>>> hot regions into hugepages.
> >>>>>
> >>>>> Motivation
> >>>>> ==========
> >>>>>
> >>>>> Since TLB is a bottleneck for many systems[1], a way to optimize TLB
> >>>>> misses (or hits) is to use huge pages. Unfortunately, using "always"
> >>>>> in THP leads to memory fragmentation and memory waste. For this reason,
> >>>>> most application guides and system administrators suggest to disable THP.
> >>>>>
> >>>>> Currently DAMON has DAMOS_HUGEPAGE, DAMOS_NONHUGEPAGE and DAMOS_COLLAPSE.
> >>>>> However, there is no way to tune the settings. It will collapse all the
> >>>>> hot regions that meet the access pattern. If the server is a bare metal
> >>>>> database or big data server, this will also lead to eventual fragmentation.
> >>>>>
> >>>>> Additionally, currently THP is set globally. Ideally, there should be a
> >>>>> way to control which tasks can use huge pages.
> >>>>
> >>>> Could you please reword for prctl(PR_SET_THP_DISABLE) like per-process control
> >>>> cases, as we discussed [1] on RFC v3?
> >>>>
> >>>>>
> >>>>> Solution
> >>>>> ========
> >>>>>
> >>>>> DAMON has now a way to autotune some of the variables and adjust quotas
> >>>>> automatically, so that DAMON is fired only under the right circumstances.
> >>>>> It would be nice to have something similar, but for huge pages.
> >>>>>
> >>>>> A new autotuning quota goal[2], damos_hugepage_mem_bp, is introduced,
> >>>>> which checks the huge page consumption to total memory consumption. This
> >>>>> new quota mechanism reuses current autotuning architecture.
> >>>>>
> >>>>> A new sample module (SAMPLE_DAMON_HPAGE) is introduced to demonstrate
> >>>>> the use of huge pages collapse autotuning. The goal is to collapse hot
> >>>>> regions of a given process into huge pages. The sample module launches
> >>>>> a kdamond thread for a certain task provided by the user through
> >>>>> taget_pid module argument. Hugepage goal autotuning will automatically
> >>>>> adjust the aggressiveness of hot region collapses.
> >>>>>
> >>>>> This sample module also has a user autotuning knob which allows the
> >>>>> user to adjust the aggressiveness of page collapsing.
> >>>>>
> >>>>> Benchmarks
> >>>>> ==========
> >>>>>
> >>>>> Huge page collapse autotuning was tested in a physicial machine with
> >>>>> MariaDB 10.5.29 and sysbench as the benchmark framework.
> >>>>>
> >>>>> The hugepage module was set up in the following way:
> >>>>>
> >>>>> # echo 1000 > min_age
> >>>>> # echo 1000 > quota_percentage_hugepage
> >>>>
> >>>> I guess this is the quota goal? What is the unit? I guess it is aparently not
> >>>> percentage? The name doesn't sound like very consistent or intuitive. How
> >>>> about hugepage_mem_bp or target_hugepage_mem_bp?
> >>> Right, we agreed to change the name. I will correct it.
> >>>>> # echo $(pidof mariadbd) > taget_pid
> >>>>> # echo on > enabled
> >>>>>
> >>>>> The goal was to achieve 5% of the total memory used as hugepage.
> >>>>
> >>>> I guess this is what the above example is setting using
> >>>> 'quotta_percentage_hugepage'? If so, it means the unit is 1/20000 ? Is this
> >>>> correct...?
> >>> I actually set it to 500. I will update the cover letter.
> >>>>> Since the database was not very big, we may not be able to achieve
> >>>>> high amount of huge pages per total memory consumption ratio.
> >>>>
> >>>> I believe this patch series will work as you explained. But, it seems bit
> >>>> weird to show a test result that doesn't demonstrate what this patch is aimed
> >>>> to achive. Could you increase the size of the database? IIRC, you were able
> >>>> to show the percentage is over-achived case in an early version.
> >>> Actually, this is what I got using the TEMPORAL quota goals. With the regular
> >>> quota goals, it actually over-achieves the goal.
> >>>
> >>> Is this an actual bug in the TEMPORAL quota goal?
> >>>>>
> >>>>> The table below shows the memory consumption over time. Timestamp is in
> >>>>> second and the memory usage in is MBytes. Gaps in the timestamp means
> >>>>> that no changes in the hugepage consumption happened over that period
> >>>>> of time in MB. The total used memory is calculated as
> >>>>> mem_total - mem free. The huge page used is calculated as
> >>>>> huge_page_anon + huge_page_shmem + huge_page_file. The table also
> >>>>> shows the huge pages to total memory ratio.
> >>>>>
> >>>>> Hugepage autotune benchmark:
> >>>>> +-----------+----------------+----------------+----------------------+
> >>>>> | timestamp | total mem used | huge page used | percentage hugepage |
> >>>>> +-----------+----------------+----------------+----------------------+
> >>>>> | 0 | 3044.988281 | 0 | 0% |
> >>>>> | 22 | 3160.207031 | 2 | 0.06% |
> >>>>> | 30 | 3250.90625 | 4 | 0.12% |
> >>>>> | 69 | 3781.238281 | 6 | 0.16% |
> >>>>> | 71 | 3822.226563 | 8 | 0.21% |
> >>>>> | 72 | 3846.578125 | 10 | 0.26% |
> >>>>> | 73 | 3852.402344 | 12 | 0.31% |
> >>>>> | 74 | 3868 | 14 | 0.36% |
> >>>>> | 75 | 3881.84375 | 104 | 2.68% |
> >>>>> | 275 | 4194.175781 | 106 | 2.52% |
> >>>>> +-----------+----------------+----------------+----------------------+
> >>>>> After second 275, no more pages are collapsed into hugepages
> >>>>>
> >>>>>
> >>>>> THP (always) benchmark:
> >>>>> +-----------+----------------+----------------+---------------------+
> >>>>> | timestamp | total mem used | huge page used | percentage hugepage |
> >>>>> +-----------+----------------+----------------+---------------------+
> >>>>> | 1 | 4489.320313 | 184 | 4.098615986 |
> >>>>> | 15 | 4581.871094 | 214 | 4.670580984 |
> >>>>> | 30 | 4757.742188 | 376 | 7.902908253 |
> >>>>> | 45 | 4937.574219 | 558 | 11.30109595 |
> >>>>> | 60 | 5147.867188 | 728 | 14.14177898 |
> >>>>> | 75 | 5407.0625 | 918 | 16.97779524 |
> >>>>> | 95 | 5668.796875 | 1040 | 18.34604455 |
> >>>>> | 105 | 5723.839844 | 1056 | 18.44915352 |
> >>>>> | 115 | 5736.84375 | 1072 | 18.68623317 |
> >>>>> | 125 | 5732.042969 | 1088 | 18.98101612 |
> >>>>> | 186 | 5753.601563 | 1184 | 20.57841488 |
> >>>>> | 246 | 5746.398438 | 1280 | 22.27482159 |
> >>>>> | 306 | 5752.128906 | 1376 | 23.92157795 |
> >>>>> | 367 | 5772.5625 | 1472 | 25.49994045 |
> >>>>> | 427 | 5832.019531 | 1568 | 26.88605536 |
> >>>>> | 488 | 5813.246094 | 1664 | 28.62428277 |
> >>>>> | 548 | 5807.621094 | 1760 | 30.30500736 |
> >>>>> | 598 | 5841.253906 | 1822 | 31.19193292 |
> >>>>> | 669 | 5982.160156 | 1854 | 30.99214918 |
> >>>>> | 931 | 5946.605469 | 1868 | 31.41287933 |
> >>>>> | 981 | 6020.207031 | 1896 | 31.49393352 |
> >>>>> | 991 | 5988.445313 | 1910 | 31.89475566 |
> >>>>> | 1011 | 5988.570313 | 1926 | 32.16126554 |
> >>>>> | 1032 | 6016.039063 | 1936 | 32.18064211 |
> >>>>> | 1575 | 6057.289063 | 1968 | 32.48978181 |
> >>>>> | 1606 | 6026.167969 | 2000 | 33.18858702 |
> >>>>> +-----------+----------------+----------------+---------------------+
> >>>>> I ignored some points to make the table shorter. Anyway, the amount
> >>>>> of memory consumption, total and huge pages, is a lot higher than
> >>>>> with DAMON hugepage autotuning.
> >>>>
> >>>> Could you further clarify why it is, and what this means
> >>> Memory fragmentation. I will add information about memory fragmentation
> >>> in the next cover letter. >>
> >>>>>
> >>>>> Performance:
> >>>>> Baseline (no THP, module off) -> 18,162.45 transactions per second
> >>>>> Hugepage autotune -> 18,211.82 transactions per second (+0.27% improvement)
> >>>>> THP always -> 18,388.3 (+1.24%)
> >>>>> THP madvise -> 18,179.25 (+0.09%)
> >>>>>
> >>>>> Improvement is due to lower TLB misses
> >>>>
> >>>> So this result says THP always is much better than the Hugepage autotune in
> >>>> terms of the performance. Maybe you want to claim Hugepage autotune is better
> >>>> in terms of the memory efficiency? Could you please clarify further?
> >>> It's better than THP "never", but worse than THP "always". THP "always" is worse
> >>> in terms of memory consumption, "always" is worse.
> >>>>>
> >>>>> Patches Sequence
> >>>>> ================
> >>>>> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
> >>>>> Patch 2 -> Module that demonstrates how to use
> >>>>> DAMOS_QUOTA_HUGEPAGE_MEM_BP and DAMOS_QUOTA_GOAL_TUNER_TEMPORAL
> >>>>> Patch 3 -> Support for DAMOS_QUOTA_HUGEPAGE_MEM_BP in sysfs-schemes
> >>>>>
> >>>>> Changes from previous versions
> >>>>> ==============================
> >>>>> RFC 4[3] -> v1
> >>>>> - Renamed config to SAMPLE_DAMON_HPAGE, file to hpage.c and
> >>>>> functions to damon_sample_hpage_...
> >>>>> - Make the module depend on TRANSPARENT_HUGEPAGE, since
> >>>>> the module will need some THP functions anyway
> >>>>> - Removed documentation, since this is just a sample module
> >>>>> - Removed DAMOS_QUOTA_HUGEPAGE_MEM_BP from
> >>>>> damos_sysfs_add_quota_score
> >>>>> - Added a short description of the module in Kconfig
> >>>>
> >>>> Thank you for continuing this work!
> >>>>
> >>>> [...]
> >>>>
> >>>>> [1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
> >>>>> [2] https://lore.kernel.org/e67f05ad-dbb9-45e6-ba30-b167a99ac67d@huawei-partners.com
> >>>>> [3] https://lore.kernel.org/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com
> >>>>> [4] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
> >>>>> [5] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
> >>>>> [6] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
> >>>>> [7] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
> >>>>> [8] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
> >>>>> [9] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/
> >>>>
> >>>> [1] https://lore.kernel.org/9f9e2159-5a6b-496f-9633-fa06c0217948@huawei-partners.com
> >>>>
> >>>>
> >>>> Thanks,
> >>>> SJ
> >>>>
> >>>> [...]
> >>>>
> >>>
> >>> SJ, once again, sorry for the late answer. Please, disregard my new patch set, I will fix
> >>> it with your feedback.
> >>>
> >>
> >> I didn't get a reply to this email.
> >
> > I sent the reply [1] weeks ago.
> >
> >>
> >> I will update the cover letter and submit a new patch set soon.
> >
> > No, please. Let's fully complete the discussion before a new version.
> >
> > [1] https://lore.kernel.org/20260620200254.82414-1-sj@kernel.org
> >
> >
> > Thanks,
> > SJ
> >
> > [...]
>
> Hi SJ,
>
> So, I finally got some stable results which make sense now.
>
> Setup: physical server with arm64 processor with 4 NUMA nodes,
> 1 TB RAM and running mariaDB 10.5.29. I use sysbench for the
> benchmark, with 20 tables and 3 million rows per table. The database
> was pinned to one of the nodes, and the benchmark framework to a
> different node. No network traffic involved in the benchmark.
>
> I forked damo and added hugepage_mem_bp support[1].
>
> I launch DAMON using this command line:
This is very helpful at understanding the test setup. Thank you for sharing!
>
> sudo ./damo start $(pidof mariadbd) \
> --monitoring_nr_regions_range 10 1000 \
> --monitoring_intervals 5000 100000 60000000 \
> --damos_quota_time 0 --damos_quota_space 128000000 \
> --damos_quota_interval 1000 \
> --damos_quota_weights 0 1 1 \
> --damos_quota_goal hugepage_mem_bp <target> \
> --damos_quota_goal_tuner temporal \
> --damos_apply_interval 50000 \
So, 50 ms DAMOS apply interval? Seems quite short to me. No big deal, though.
> --damos_access_rate 0 max --damos_age 50 max \
> --damos_action collapse --debug_damon
FYI, damo supports human friendly formats. E.g.,
--monitoring_intervals 5ms 100ms 60s \
--damos_quota_space 128MB --damos_quota_interval 1s \
--damos_apply_interval 50ms
>
> <target> was 1000 to taget 10% hugepage to total memory ratio, or
> 2500 to target 25%. Tuner was also tested with consistent and
> temporal.
>
> Results
> =======
> After the last timestamp, there was no change in huge page use, and
> the total huge page to memory consumption ratio barely moved.
>
> Timestamp is measured in seconds, and the memory consumption (total
> and huge page) is in MB.
>
> hugepage_mem_bp: 1000
> goal tuner: temporal
>
> +-----------+----------------+----------------+----------------------+
> | timestamp | total mem used | huge page used | percentage hugepage |
> +-----------+----------------+----------------+----------------------+
> | 0 | 16945.04297 | 0 | 0 |
> | 7 | 17008.69531 | 74 | 0.435071583 |
> | 8 | 17036.40234 | 194 | 1.138738074 |
> | 9 | 17017.01563 | 314 | 1.845211916 |
> | 10 | 17029.67969 | 434 | 2.548491856 |
> | 61 | 17111.30859 | 584 | 3.412947623 |
> | 75 | 17068.51953 | 612 | 3.58554823 |
> | 90 | 17098.84766 | 638 | 3.731245595 |
> | 105 | 17076.32031 | 664 | 3.888425538 |
> | 120 | 17071.05859 | 694 | 4.065360072 |
> | 135 | 17088.94531 | 722 | 4.22495354 |
> | 150 | 17101.42578 | 746 | 4.362209383 |
> | 165 | 17097.33984 | 776 | 4.53871776 |
> | 180 | 17133.88281 | 804 | 4.692456513 |
> | 195 | 17099.12891 | 832 | 4.865744943 |
> | 201 | 17103.5 | 852 | 4.981436548 |
> | 202 | 17077.84375 | 862 | 5.047475622 |
> | 203 | 17088.16406 | 916 | 5.360435426 |
> | 204 | 17126.34766 | 1046 | 6.107548562 |
> | 205 | 17093.84375 | 1176 | 6.879669764 |
> | 206 | 17142.77734 | 1298 | 7.571701913 |
> | 207 | 17129.86719 | 1428 | 8.336316822 |
> | 208 | 17099.76953 | 1556 | 9.099537846 |
> | 209 | 17149.17969 | 1686 | 9.831374041 |
> | 210 | 17097.30859 | 1754 | 10.25892462 |
> +-----------+----------------+----------------+----------------------+
I saw you added description of all results at the end. But adding it for each
result would be nicer for readers. E.g., you could say,
"As expected, ~10 % huge page ratio is achieved."
Or, you could make tables shorter by cutting more lines, keeping the height ~10
rows per table?
>
> hugepage_mem_bp: 1000
> goal tuner: consistent
>
> +-----------+----------------+----------------+----------------------+
> | timestamp | total mem used | huge page used | percentage hugepage |
> +-----------+----------------+----------------+----------------------+
> | 0 | 16955.24609 | 0 | 0 |
> | 34 | 17039.71875 | 106 | 0.622075995 |
> | 35 | 17022.21875 | 224 | 1.315927161 |
> | 36 | 17070.08594 | 344 | 2.015221255 |
> | 37 | 17005.86719 | 464 | 2.728470091 |
> | 38 | 17028.92188 | 542 | 3.182820404 |
> | 78 | 17009.47656 | 554 | 3.257007927 |
> | 79 | 17051.82031 | 572 | 3.354480575 |
> | 90 | 17048.92188 | 596 | 3.495822225 |
> | 105 | 17086.22656 | 624 | 3.652064414 |
> | 120 | 17102.49609 | 654 | 3.824003212 |
> | 135 | 17081.31641 | 680 | 3.980957813 |
> | 150 | 17092.90625 | 706 | 4.130368409 |
> | 165 | 17093.69531 | 736 | 4.305681051 |
> | 180 | 17053.08984 | 764 | 4.480126517 |
> | 195 | 17095.73047 | 788 | 4.609337995 |
> | 210 | 17086.20703 | 818 | 4.787487349 |
> | 225 | 17095.04297 | 846 | 4.948803004 |
> | 226 | 17057.95703 | 848 | 4.971286998 |
> | 227 | 17101.46484 | 858 | 5.017114077 |
> | 228 | 17053.90625 | 896 | 5.253928261 |
> | 229 | 17061.48047 | 1016 | 5.954934578 |
> | 230 | 17097.48828 | 1136 | 6.644250789 |
> | 231 | 17080.42188 | 1256 | 7.353448347 |
> | 232 | 17118.92969 | 1376 | 8.037885692 |
> | 233 | 17100.50391 | 1496 | 8.748280216 |
> | 234 | 17110.80859 | 1616 | 9.444322816 |
> | 235 | 17138.17188 | 1736 | 10.12943512 |
> | 236 | 17060.17578 | 1856 | 10.87913761 |
> | 237 | 17118.92578 | 1976 | 11.54278034 |
> | 238 | 17119.28516 | 2096 | 12.24350188 |
> | 239 | 17098.89063 | 2216 | 12.95990511 |
> | 240 | 17135.44531 | 2334 | 13.62088908 |
> | 241 | 17097.58594 | 2454 | 14.35290344 |
> | 242 | 17134.69531 | 2574 | 15.02215215 |
> | 243 | 17127.96094 | 2694 | 15.72866735 |
> | 244 | 17097.53516 | 2812 | 16.44681514 |
> | 245 | 17132.55078 | 2932 | 17.11362212 |
> | 246 | 17117.95313 | 3052 | 17.82923448 |
> | 247 | 17154.30469 | 3172 | 18.49098554 |
> | 248 | 17145.55078 | 3292 | 19.20031641 |
> | 249 | 17138.36719 | 3410 | 19.89687794 |
> | 250 | 17163.12109 | 3532 | 20.57900763 |
> +-----------+----------------+----------------+----------------------+
Seems the table bit long to me. When you add this to the cover letter, I think
you could further cut some rows. Maybe showing the rows for ~2% jumps? E.g.,
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 16955.24609 | 0 | 0 |
| 36 | 17070.08594 | 344 | 2.015221255 |
| 150 | 17092.90625 | 706 | 4.130368409 |
| 230 | 17097.48828 | 1136 | 6.644250789 |
| 232 | 17118.92969 | 1376 | 8.037885692 |
| 235 | 17138.17188 | 1736 | 10.12943512 |
| 238 | 17119.28516 | 2096 | 12.24350188 |
| 241 | 17097.58594 | 2454 | 14.35290344 |
| 244 | 17097.53516 | 2812 | 16.44681514 |
| 247 | 17154.30469 | 3172 | 18.49098554 |
| 250 | 17163.12109 | 3532 | 20.57900763 |
+-----------+----------------+----------------+----------------------+
>
> hugepage_mem_bp: 2500
> goal tuner: temporal
>
> +-----------+----------------+----------------+----------------------+
> | timestamp | total mem used | huge page used | percentage hugepage |
> +-----------+----------------+----------------+----------------------+
> | 0 | 17010.31641 | 0 | 0 |
> | 9 | 17063.6875 | 50 | 0.2930199 |
> | 10 | 17051.75781 | 170 | 0.996964664 |
> | 11 | 17059.625 | 290 | 1.699920133 |
> | 12 | 17053.72656 | 410 | 2.404166611 |
> | 13 | 17082.44141 | 528 | 3.090893084 |
> | 14 | 17097.22266 | 530 | 3.099918687 |
> | 60 | 17133.85547 | 572 | 3.338419663 |
> | 75 | 17149.26563 | 598 | 3.487029784 |
> | 90 | 17192.07813 | 626 | 3.641211932 |
> | 105 | 17196.34766 | 654 | 3.80313316 |
> | 120 | 17221.44531 | 682 | 3.960178647 |
> | 135 | 17225.36719 | 708 | 4.110217172 |
> | 150 | 17220.15625 | 736 | 4.274061102 |
> | 165 | 17223.66406 | 764 | 4.435757672 |
> | 181 | 17199.76172 | 790 | 4.593086886 |
> | 195 | 17139.11328 | 818 | 4.772708988 |
> | 205 | 17185.85547 | 862 | 5.015752644 |
> | 206 | 17228.63281 | 978 | 5.67659669 |
> | 207 | 17194.80469 | 1094 | 6.362386895 |
> | 208 | 17222.77734 | 1206 | 7.002354939 |
> | 209 | 17177.09766 | 1320 | 7.68465096 |
> | 210 | 17182.23828 | 1428 | 8.310907907 |
> | 211 | 17196.77734 | 1542 | 8.966796332 |
> | 212 | 17205.57031 | 1664 | 9.671286507 |
> | 213 | 17227.39844 | 1784 | 10.35559726 |
> | 214 | 17245.17969 | 1904 | 11.04076637 |
> | 215 | 17240.45703 | 2024 | 11.73982799 |
> | 216 | 17218.85156 | 2144 | 12.45146921 |
> | 217 | 17183.63281 | 2264 | 13.17532809 |
> | 218 | 17217.08984 | 2384 | 13.84670709 |
> | 219 | 17176.72266 | 2504 | 14.57786826 |
> | 220 | 17234.79688 | 2624 | 15.22501262 |
> | 221 | 17221.20703 | 2744 | 15.93384247 |
> | 222 | 17258.91016 | 2864 | 16.59432707 |
> | 223 | 17248.64063 | 2984 | 17.29991403 |
> | 224 | 17227.35156 | 3104 | 18.0178595 |
> | 225 | 17194.83594 | 3224 | 18.74981542 |
> | 226 | 17216.30078 | 3344 | 19.42345247 |
> | 227 | 17205.71875 | 3464 | 20.13284101 |
> | 228 | 17222.83594 | 3584 | 20.80958103 |
> | 229 | 17232.32031 | 3704 | 21.49449368 |
> | 230 | 17269.49219 | 3824 | 22.14309465 |
> | 231 | 17247.55469 | 3944 | 22.86700968 |
> | 232 | 17248.90234 | 4064 | 23.56091952 |
> | 233 | 17229.21875 | 4184 | 24.28432804 |
> | 234 | 17221.28125 | 4304 | 24.99233325 |
> | 235 | 17229.37109 | 4424 | 25.67708349 |
> +-----------+----------------+----------------+----------------------+
Again, table looks bit long to me. In the final version of the cover letter,
maybe we can show only ~3% jumps? E.g.,
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 17010.31641 | 0 | 0 |
| 13 | 17082.44141 | 528 | 3.090893084 |
| 207 | 17194.80469 | 1094 | 6.362386895 |
| 212 | 17205.57031 | 1664 | 9.671286507 |
| 216 | 17218.85156 | 2144 | 12.45146921 |
| 220 | 17234.79688 | 2624 | 15.22501262 |
| 224 | 17227.35156 | 3104 | 18.0178595 |
| 229 | 17232.32031 | 3704 | 21.49449368 |
| 233 | 17229.21875 | 4184 | 24.28432804 |
| 235 | 17229.37109 | 4424 | 25.67708349 |
+-----------+----------------+----------------+----------------------+
>
> hugepage_mem_bp: 1000
> goal tuner: consist
>
> +-----------+----------------+----------------+----------------------+
> | timestamp | total mem used | huge page used | percentage hugepage |
> +-----------+----------------+----------------+----------------------+
> | 0 | 17125.85156 | 0 | 0 |
> | 38 | 17081.23438 | 76 | 0.444932716 |
> | 39 | 17133.11719 | 196 | 1.143983304 |
> | 40 | 17119.83984 | 316 | 1.84581166 |
> | 41 | 17116.48438 | 436 | 2.547252055 |
> | 60 | 17109.72656 | 554 | 3.237924335 |
> | 75 | 17158.79297 | 600 | 3.496749457 |
> | 90 | 17164.11328 | 628 | 3.65879664 |
> | 105 | 17205 | 654 | 3.801220575 |
> | 120 | 17176.01953 | 682 | 3.970652215 |
> | 136 | 17172.19922 | 710 | 4.134589816 |
> | 150 | 17154.96484 | 738 | 4.3019616 |
> | 165 | 17190.66797 | 764 | 4.444271749 |
> | 180 | 17177.66016 | 792 | 4.610639591 |
> | 195 | 17202.01563 | 822 | 4.778509786 |
> | 210 | 17160.23047 | 848 | 4.941658572 |
> | 216 | 17147.09766 | 898 | 5.237037882 |
> | 217 | 17180.72656 | 1018 | 5.925244176 |
> | 218 | 17179.74609 | 1138 | 6.624079272 |
> | 219 | 17151.43359 | 1258 | 7.334663853 |
> | 220 | 17180.86719 | 1378 | 8.020549749 |
> | 221 | 17201.65625 | 1498 | 8.708463756 |
> | 222 | 17184.45703 | 1618 | 9.415485151 |
> | 223 | 17174.21094 | 1718 | 10.00337079 |
> | 224 | 17174.90234 | 1800 | 10.48040894 |
> | 225 | 17204.64063 | 1874 | 10.89241002 |
> | 226 | 17187.82031 | 1980 | 11.51978531 |
> | 227 | 17145.08594 | 2100 | 12.24840755 |
> | 228 | 17144.25781 | 2220 | 12.948942 |
> | 229 | 17171.44141 | 2338 | 13.61563042 |
> | 230 | 17175.02344 | 2458 | 14.31147974 |
> | 231 | 17150.30469 | 2578 | 15.03180292 |
> | 232 | 17148.73438 | 2698 | 15.73293948 |
> | 233 | 17143.48438 | 2818 | 16.4377319 |
> | 234 | 17167.57422 | 2938 | 17.11365836 |
> | 235 | 17157.11328 | 3058 | 17.82351116 |
> | 236 | 17151.45703 | 3178 | 18.52903805 |
> | 237 | 17155.85938 | 3298 | 19.22375282 |
> | 238 | 17188.00781 | 3418 | 19.88595791 |
> | 239 | 17151.66406 | 3536 | 20.61607543 |
> | 240 | 17137.38281 | 3656 | 21.33347921 |
> | 241 | 17165.32422 | 3776 | 21.99783675 |
> | 242 | 17158.48438 | 3896 | 22.70596817 |
> | 243 | 17122.70313 | 4016 | 23.45424067 |
> | 244 | 17151.28516 | 4136 | 24.114811 |
> | 245 | 17188.16797 | 4256 | 24.76121951 |
> | 246 | 17150.58984 | 4376 | 25.51515744 |
> | 247 | 17178.125 | 4496 | 26.17282154 |
> | 248 | 17130.97266 | 4616 | 26.94534684 |
> | 249 | 17149.64063 | 4736 | 27.61573903 |
> | 250 | 17175.5 | 4856 | 28.27283049 |
> | 251 | 17141.30859 | 4978 | 29.04095666 |
> | 252 | 17168.22266 | 5098 | 29.69439587 |
> | 253 | 17158.42578 | 5218 | 30.41071522 |
> | 254 | 17175.84375 | 5338 | 31.07853144 |
> | 255 | 17173.60156 | 5458 | 31.78133591 |
> | 256 | 17188.17188 | 5578 | 32.45254958 |
> | 257 | 17217.83203 | 5698 | 33.09359732 |
> | 258 | 17182.50781 | 5818 | 33.86001661 |
> | 259 | 17194.44922 | 5936 | 34.52276909 |
> | 260 | 17199.66406 | 6056 | 35.20999002 |
> | 261 | 17188.90234 | 6176 | 35.93015933 |
> | 262 | 17204.27344 | 6296 | 36.59555879 |
> | 263 | 17202.03516 | 6416 | 37.29791238 |
> | 264 | 17207.71484 | 6536 | 37.98296322 |
> | 265 | 17224.46094 | 6656 | 38.64271877 |
> | 266 | 17198.29297 | 6776 | 39.39925906 |
> | 267 | 17200.13281 | 6896 | 40.09271367 |
> | 268 | 17204.625 | 7014 | 40.76810741 |
> | 269 | 17210.91406 | 7134 | 41.45044228 |
> | 270 | 17203.98438 | 7254 | 42.16465118 |
> | 271 | 17206.08203 | 7374 | 42.85693853 |
> | 272 | 17210.62891 | 7494 | 43.54285971 |
> | 273 | 17202.55859 | 7614 | 44.26085782 |
> | 274 | 17223.07813 | 7734 | 44.90486511 |
> | 275 | 17207.21875 | 7762 | 45.10897498 |
> +-----------+----------------+----------------+----------------------+
Again, seems long for the final version of the cover letter? We could show for
~5% jumps?
+-----------+----------------+----------------+----------------------+
| timestamp | total mem used | huge page used | percentage hugepage |
+-----------+----------------+----------------+----------------------+
| 0 | 17125.85156 | 0 | 0 |
| 216 | 17147.09766 | 898 | 5.237037882 |
| 223 | 17174.21094 | 1718 | 10.00337079 |
| 231 | 17150.30469 | 2578 | 15.03180292 |
| 239 | 17151.66406 | 3536 | 20.61607543 |
| 246 | 17150.58984 | 4376 | 25.51515744 |
| 253 | 17158.42578 | 5218 | 30.41071522 |
| 260 | 17199.66406 | 6056 | 35.20999002 |
| 267 | 17200.13281 | 6896 | 40.09271367 |
| 275 | 17207.21875 | 7762 | 45.10897498 |
+-----------+----------------+----------------+----------------------+
>
> From this, we can conclude that the huge page autotuner works fine, achieving
> the target. When using consistent autotuner, it actually over-achieves the
> target, which is expected, since quota esz_bp is not set to 0 to cap the
> DAMOS policy.
>
> [1] https://github.com/asierHuawei/damo/commit/79ae1a4ab1c012a7161db85a000d14f08fa36736
>
> Let me know what you think.
Looks good! Let's proceed to the next version of the patch series with this
great test results!
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-07-13 14:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 15:03 [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning gutierrez.asier
2026-06-16 15:03 ` [PATCH v1 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE " gutierrez.asier
2026-06-16 15:20 ` sashiko-bot
2026-06-16 19:33 ` Gutierrez Asier
2026-06-17 3:31 ` SeongJae Park
2026-06-16 15:03 ` [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing gutierrez.asier
2026-06-16 15:21 ` sashiko-bot
2026-06-16 19:27 ` Gutierrez Asier
2026-06-17 4:09 ` SeongJae Park
2026-06-17 4:04 ` SeongJae Park
2026-06-18 0:16 ` SeongJae Park
2026-06-18 0:19 ` SeongJae Park
2026-06-18 11:51 ` Gutierrez Asier
2026-06-18 14:57 ` SeongJae Park
2026-06-18 14:59 ` Gutierrez Asier
2026-06-18 15:08 ` SeongJae Park
2026-06-17 16:12 ` Julian Braha
2026-06-18 0:18 ` SeongJae Park
2026-06-16 15:03 ` [PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric gutierrez.asier
2026-06-16 15:21 ` sashiko-bot
2026-06-16 19:35 ` Gutierrez Asier
2026-06-17 4:15 ` SeongJae Park
2026-06-17 4:16 ` SeongJae Park
2026-06-17 1:44 ` [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning SeongJae Park
2026-06-20 17:11 ` Gutierrez Asier
2026-06-20 20:02 ` SeongJae Park
2026-07-07 13:31 ` Gutierrez Asier
2026-07-07 14:10 ` SJ Park
2026-07-07 14:25 ` Gutierrez Asier
2026-07-08 1:22 ` SJ Park
2026-07-08 14:50 ` Gutierrez Asier
2026-07-09 0:52 ` SJ Park
2026-07-06 15:03 ` Gutierrez Asier
2026-07-06 15:16 ` SJ Park
2026-07-13 11:30 ` Gutierrez Asier
2026-07-13 14:45 ` SJ Park [this message]
2026-07-13 15:04 ` Gutierrez Asier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260713144513.39596-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=artem.kuzin@huawei.com \
--cc=damon@lists.linux.dev \
--cc=gutierrez.asier@huawei-partners.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stepanov.anatoly@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=yanquanmin1@huawei.com \
--cc=zuoze1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.