| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <e67f05ad-dbb9-45e6-ba30-b167a99ac67d@huawei-partners.com> Date: Wed, 11 Feb 2026 14:29:41 +0300 From: Gutierrez Asier <gutierrez.asier@...wei-partners.com> To: SeongJae Park <sj@...nel.org> CC: <artem.kuzin@...wei.com>, <stepanov.anatoly@...wei.com>, <wangkefeng.wang@...wei.com>, <yanquanmin1@...wei.com>, <zuoze1@...wei.com>, <damon@...ts.linux.dev>, <akpm@...ux-foundation.org>, <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH v1 0/4] mm/damon: Support hot application detections Hi SeongJae, On 2/11/2026 9:59 AM, SeongJae Park wrote: > On Mon, 2 Feb 2026 14:56:45 +0000 <gutierrez.asier@...wei-partners.com> wrote: > >> From: Asier Gutierrez <gutierrez.asier@...wei-partners.com> >> >> Overview >> ---------- >> >> This patch set introduces a new dynamic mechanism for detecting hot applications >> and hot regions in those applications. >> >> Motivation >> ----------- >> >> Currently DAMON requires the system administrator to provide information about >> which application needs to be monitored and all the parameters. Ideally this >> should be done automatically, with minimal intervention from the system >> administrator. >> >> >> Since TLB is a bottleneck for many systems, 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. >> >> We would like to detect: 1. which applications are hot in the system and 2. >> which memory regions are hot in order to collapse those regions. >> >> >> Solution >> ----------- >> >> ┌────────────┐ ┌────────────┐ >> │Damon_module│ │Task_monitor│ >> └──────┬─────┘ └──────┬─────┘ >> │ start │ >> │───────────────────────>│ >> │ │ >> │ │────┐ >> │ │ │ calculate task load >> │ │<───┘ >> │ │ >> │ │────┐ >> │ │ │ sort tasks >> │ │<───┘ >> │ │ >> │ │────┐ >> │ │ │ start kdamond for top 3 tasks >> │ │<───┘ >> ┌──────┴─────┐ ┌──────┴─────┐ >> │Damon_module│ │Task_monitor│ >> └────────────┘ └────────────┘ >> >> >> We calculate the task load base on the sum of all the utime for all the threads >> in a given task. Once we get total utime, we use the exponential load average >> provided by calc_load. The tasks that become cold, the kdamond will be stopped >> for them. >> >> In each kdamond, we start with a high min_access value. Our goal is to find the >> "maximum" min_access value at which point the DAMON action is applied. In each >> cycle, if no action is applied, we lower the min_access. >> >> Regarding the action, we introduce a new action: DAMOS_COLLAPSE. This allows us >> collapse synchronously and avoid polluting khugepaged and other parts of the MM >> subsystem with DAMON stuff. DAMOS_HUGEPAGE eventually calls hugepage_madvise, >> which needs the correct vm_flags_t set. >> >> Benchmark >> ----------- >> >> Asier Gutierrez (4): >> mm/damon: Generic context creation for modules >> mm/damon: Support for synchrounous huge pages collapse >> mm/damon: New module with hot application detection >> documentation/mm/damon: Documentation for the dynamic_hugepages >> module >> >> .../mm/damon/dynamic_hugepages.rst (new) | 173 ++++++ >> include/linux/damon.h | 1 + >> mm/damon/Kconfig | 7 + >> mm/damon/Makefile | 1 + >> mm/damon/dynamic_hugepages.c (new) | 579 ++++++++++++++++++ >> mm/damon/lru_sort.c | 6 +- >> mm/damon/modules-common.c | 7 +- >> mm/damon/modules-common.h | 5 +- >> mm/damon/reclaim.c | 5 +- >> mm/damon/vaddr.c | 3 + >> 10 files changed, 778 insertions(+), 9 deletions(-) >> create mode 100644 Documentation/admin-guide/mm/damon/dynamic_hugepages.rst >> create mode 100644 mm/damon/dynamic_hugepages.c > > By the way, I proposed [1] an LSF/MM/BPF session for access-aware THP today. I > also mentioned this patch series on the proposal as one of potential discussion > topics, and Cc-ed Asier. > > I just wanted to make sure that the proposal is never a sort of implicit > request to hold the progress of this patch series. Please continue discussions > and revisioning of this patch series regardless of the proposed LSF/MM/BPF > session. > > [1] https://lore.kernel.org/20260211050729.69719-1-sj@kernel.org > > > Thanks, > SJ > > [...] > Yes, I keep working on this, I haven't given up. I was thinking about your comments and about the overall idea. When you mentioned goals and autotuning, were you referring to DAMOS_QUOTA_USER_INPUT? The idea was to adjust the min_nr_accesses for region and I haven't found a way to adjust the damos_access_pattern using goals and quotas. If there is a way to do it, it may be a good idea to reuse already existing components. Also, I thought about moving part of the logic to user space. What do you think if we leave the hot application detection mechanism in the user space and we keep the THP part and autotuning in the kernel? Maybe this way we can move forward easier and eventually merge it in the mainstream. -- Asier Gutierrez Huawei
Powered by blists - more mailing lists