Re: [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning
Gutierrez Asier <[email protected]>
| Newsgroups | dev.linux.lists.damon,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 7/13/2026 5:45 PM, SJ Park wrote: > On Mon, 13 Jul 2026 14:30:40 +0300 Gutierrez Asier <[email protected]> wrote: > >> Hi SJ, >> >> On 7/6/2026 6:16 PM, SJ Park wrote: >>> On Mon, 6 Jul 2026 18:03:03 +0300 Gutierrez Asier <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>>> From: Asier Gutierrez <[email protected]> >>>>>>> >>>>>>> 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/[email protected] >>>>>>> [3] https://lore.kernel.org/[email protected] >>>>>>> [4] https://lore.kernel.org/[email protected] >>>>>>> [5] https://lore.kernel.org/[email protected] >>>>>>> [6] https://lore.kernel.org/[email protected] >>>>>>> [7] https://lore.kernel.org/[email protected] >>>>>>> [8] https://lore.kernel.org/[email protected] >>>>>>> [9] https://lore.kernel.org/all/[email protected]/ >>>>>> >>>>>> [1] https://lore.kernel.org/[email protected] >>>>>> >>>>>> >>>>>> 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/[email protected] >>> >>> >>> 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! Yes, I will make the tables shorter. I just wanted to show how the memory consumption changes over time, but I guess I can refer to this email in the new cover letter. > > Thanks, > SJ > > [...] -- Asier Gutierrez Huawei