From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6544F3DBD5D; Tue, 24 Mar 2026 13:57:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774360648; cv=none; b=jaziB79ZwdTUe7T5XDZq8l2IIeSiCqA/e/SLeSvJ9wnOSS3xnIVBv06wEwjptQRfZkYFPYRpI0ngQ+8WkwRjZoHSndcb2/bkylHndTzSohtHvJWVhDYUtI4uGrQmvjGbNke3MRj0Mmi9DpYpno2XthMtnmI5VnJJoh2jKtMgSlo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774360648; c=relaxed/simple; bh=RDbm4GnvopEJDy8DndVV80iyXCu/gZDbUcEaCHeNa8I=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=o8gEjKjofP9uqudph3AM6rlGfga8wT+jhHdKQYqIvzLYqdJbsjRY4jS3wgjuYTl3f9wz7jRrF7zzsJyV9Bp8iI32PczzJClUrfXENyjFMD9Zdm0UzethuU60XZ/CbvDL/mokqz4tEtHWie0eaQwRFuO0YTXSqo1M+9WtzcK0bAU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei-partners.com; spf=pass smtp.mailfrom=huawei-partners.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei-partners.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei-partners.com Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fgBRw5T95zJ46Zl; Tue, 24 Mar 2026 21:57:16 +0800 (CST) Received: from mscpeml500003.china.huawei.com (unknown [7.188.49.51]) by mail.maildlp.com (Postfix) with ESMTPS id B4F9340086; Tue, 24 Mar 2026 21:57:23 +0800 (CST) Received: from [10.123.123.154] (10.123.123.154) by mscpeml500003.china.huawei.com (7.188.49.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 24 Mar 2026 16:57:23 +0300 Message-ID: <48580762-eec3-49b6-b17a-59fa486bebec@huawei-partners.com> Date: Tue, 24 Mar 2026 16:57:22 +0300 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE. To: SeongJae Park CC: , , , , , , , , , , , , , , , , , References: <20260324003952.86819-1-sj@kernel.org> Content-Language: en-US From: Gutierrez Asier In-Reply-To: <20260324003952.86819-1-sj@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: mscpeml100003.china.huawei.com (10.199.174.67) To mscpeml500003.china.huawei.com (7.188.49.51) On 3/24/2026 3:39 AM, SeongJae Park wrote: > Hello Asier, > > On Mon, 23 Mar 2026 14:56:45 +0000 wrote: > >> From: Asier Gutierrez >> >> 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 +------------------+----------+----------+----------+ | | 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 | +------------------+----------+----------+----------+ > >> >> Changes >> --------- >> v1-v2: >> Added benchmarks >> Added damos_filter_type documentation for new action to fix kernel-doc > > Please add Changelog on the commentary section [1]. Also, please consider > adding links to previous versions. > >> >> Signed-off-by: Asier Gutierrez >> --- >> Documentation/mm/damon/design.rst | 4 ++++ >> include/linux/damon.h | 2 ++ >> mm/damon/sysfs-schemes.c | 4 ++++ >> mm/damon/vaddr.c | 3 +++ >> tools/testing/selftests/damon/sysfs.py | 11 ++++++----- >> 5 files changed, 19 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst >> index 838b14d22519..405142641e55 100644 >> --- a/Documentation/mm/damon/design.rst >> +++ b/Documentation/mm/damon/design.rst >> @@ -467,6 +467,10 @@ that supports each action are as below. >> Supported by ``vaddr`` and ``fvaddr`` operations set. When >> TRANSPARENT_HUGEPAGE is disabled, the application of the action will just >> fail. >> + - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``. >> + Supported by ``vaddr`` and ``fvaddr`` operations set. When >> + TRANSPARENT_HUGEPAGE is disabled, the application of the action will just >> + fail. >> - ``lru_prio``: Prioritize the region on its LRU lists. >> Supported by ``paddr`` operations set. >> - ``lru_deprio``: Deprioritize the region on its LRU lists. >> diff --git a/include/linux/damon.h b/include/linux/damon.h >> index d9a3babbafc1..6941113968ec 100644 >> --- a/include/linux/damon.h >> +++ b/include/linux/damon.h >> @@ -121,6 +121,7 @@ struct damon_target { >> * @DAMOS_PAGEOUT: Reclaim the region. >> * @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE. >> * @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE. >> + * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE. >> * @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists. >> * @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists. >> * @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions. >> @@ -140,6 +141,7 @@ enum damos_action { >> DAMOS_PAGEOUT, >> DAMOS_HUGEPAGE, >> DAMOS_NOHUGEPAGE, >> + DAMOS_COLLAPSE, >> DAMOS_LRU_PRIO, >> DAMOS_LRU_DEPRIO, >> DAMOS_MIGRATE_HOT, >> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c >> index 5186966dafb3..aa08a8f885fb 100644 >> --- a/mm/damon/sysfs-schemes.c >> +++ b/mm/damon/sysfs-schemes.c >> @@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = { >> .action = DAMOS_NOHUGEPAGE, >> .name = "nohugepage", >> }, >> + { >> + .action = DAMOS_COLLAPSE, >> + .name = "collapse", >> + }, >> { >> .action = DAMOS_LRU_PRIO, >> .name = "lru_prio", >> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c >> index b069dbc7e3d2..dd5f2d7027ac 100644 >> --- a/mm/damon/vaddr.c >> +++ b/mm/damon/vaddr.c >> @@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx, >> case DAMOS_NOHUGEPAGE: >> madv_action = MADV_NOHUGEPAGE; >> break; >> + case DAMOS_COLLAPSE: >> + madv_action = MADV_COLLAPSE; >> + break; >> case DAMOS_MIGRATE_HOT: >> case DAMOS_MIGRATE_COLD: >> return damos_va_migrate(t, r, scheme, sz_filter_passed); >> diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py >> index 3aa5c91548a5..c6476e63f4fb 100755 >> --- a/tools/testing/selftests/damon/sysfs.py >> +++ b/tools/testing/selftests/damon/sysfs.py >> @@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump): >> 'pageout': 2, >> 'hugepage': 3, >> 'nohugeapge': 4, >> - 'lru_prio': 5, >> - 'lru_deprio': 6, >> - 'migrate_hot': 7, >> - 'migrate_cold': 8, >> - 'stat': 9, >> + 'collapse': 5 > > Comman is missed? > >> + 'lru_prio': 6, >> + 'lru_deprio': 7, >> + 'migrate_hot': 8, >> + 'migrate_cold': 9, >> + 'stat': 10, >> } >> assert_true(dump['action'] == action_val[scheme.action], 'action', dump) >> assert_true(dump['apply_interval_us'] == scheme. apply_interval_us, >> -- >> 2.43.0 > > Other than the selftest part, code looks good. Please consider dropping RFC > tag from the next spin. Clarifying more details about the test would be > helpful, though. > > [1] https://docs.kernel.org/process/submitting-patches.html#commentary > > > Thanks, > SJ > SJ, should I remove the RFC tag for the next version? -- Asier Gutierrez Huawei