From patchwork Fri Jan 10 18:52:28 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 13935390 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D825DE7719D for ; Fri, 10 Jan 2025 18:52:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75A278D0005; Fri, 10 Jan 2025 13:52:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 70ADF6B00CE; Fri, 10 Jan 2025 13:52:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AA938D0005; Fri, 10 Jan 2025 13:52:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 39B1F6B00CD for ; Fri, 10 Jan 2025 13:52:44 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DB48C140E2F for ; Fri, 10 Jan 2025 18:52:43 +0000 (UTC) X-FDA: 82992438606.26.F2D73B6 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf28.hostedemail.com (Postfix) with ESMTP id 40BF4C000E for ; Fri, 10 Jan 2025 18:52:42 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JSdkNg38; spf=pass (imf28.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736535162; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GZJCyhbmT9Ofq01qEDHkhzgLr7w65xI6JzaGNEKdt0A=; b=6zcdWDx0ELwKGL2egNVR0XFSitJ9ud6QAJfd+jTfptgWkgElsbyU7DoKkG84dNBe8lmCOU LcuVq+wcm+1s9jQMqt2VDmF3EE9+DmqRKCilTL/y8hAVKzant0qpnYcLuqhFhIOZk93EUw jaZWZ8wQ9MtUfJKoIm9UfQAM2+ZuP8g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736535162; a=rsa-sha256; cv=none; b=ZjeKr1IPtPL35KRHGYD+e/SJWFdZ0qvVMA7/b5o8ZYbjfj+MNh1tTcF1V23rxKMJ2UqUaa RnZa7g6w/elNH2cSK9kHjPk40sUyaPwWM19EuluJx9MlydxjMftz7Lone00CLFGwuQVjZv ytCc2fj9xd8g7PwmlG+F0bFivmPI7Ak= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JSdkNg38; spf=pass (imf28.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 196A3A428D0; Fri, 10 Jan 2025 18:50:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D497C4CED6; Fri, 10 Jan 2025 18:52:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736535161; bh=OhiJLdYW/SZA1DPs4LYjgcwHYXKVNp0i99jYURYdR3o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JSdkNg38oRiYAiL0Y2handSc2PdlVRbvyiaLZ/O+joMpFP6bCxqOTZdMJ5SG+GfrO XfzJamDF8rQnvYjJ7D4HltWOKGUCIb66WUyFp1oKFt0Mo8+zKE/r8llSzwzu+YKsb0 RFoHWE5V76uFUCn9zWR/t82ufSz3FeHDOM++OkbOqaGIFMsPR+ed2OrVTbf57+TTEI CWlLTHtOo+skOX/YkTP2g8cfRkhhFJf0B5SULirlOaBuF4JPmJK/Lr9zO2Drl+4sse UwQSQwpxXb4D7Z8VGFofM64eHuOQi7Opdm5hKv9kSJgEFbCn2ioMowaXfoeoX2NbwO iwTc+D67NdTow== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Jonathan Corbet , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1/5] Docs/mm/damon/design: add monitoring parameters tuning guide Date: Fri, 10 Jan 2025 10:52:28 -0800 Message-Id: <20250110185232.54907-2-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250110185232.54907-1-sj@kernel.org> References: <20250110185232.54907-1-sj@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 40BF4C000E X-Stat-Signature: qro91wiw3piwkokjzf113pjef8fycih3 X-Rspam-User: X-HE-Tag: 1736535162-872076 X-HE-Meta: U2FsdGVkX19GTKsW81Y24Z5ZRVuKR5SAuVoNJoW1L/jRdEGg4thqd7KGGVHmWXYc4wIP3AehzgAuFbLO02qLmQbMTH8ZBQmxcbum06p/YfBWIOvEKQyD+gGlG05ZSCX6IOC8rE5uNKXDZTVFmdUg7whlF6vG11nlgHpzOoRjPFIWcMChlcOTtiIe6X5220WFCC2uG+GIEEfWFRk5PDc3q7SMXd6d0EVbwVRCZm2+k8yTr1SApx23FuiIA/EReOzqKdZnOb8CFENil0Q3mEmf8wtnkZN+kZ7Yp1LypypwgMuBguNd5Kn9IW34Ap2CX06fZAubOtac+mHKcB4YU7HJUW8wS8n7bHBiqUuK0l9AcQ3+RNAIrNJAaNFjsHF1abkCWbiSISkHEEXMbANMlQdCrM4ZioEfsy8AtGIH6fZhgvyyf2XVJaNuaDomKxoYOnHFtKo1yIal9uce7+E2XdbZVcTMJhZII/PSVxKL4LSPhsqdRcXPSZk+Lc8BxXhU33lflmekoYv4+67G7yNDFPpJ1LwH7TcNLL17dcKlBaPvYPgnbilziR8VsZFExoktc8ECZwWP6yhu+IbO6EeAlOfBtWaabBQIQ+khYcNBu9qhiztntF6WLcZZcKv6s4ycHODqBZ62q+URPe0HMDJDJvOmPN/70neuYtPKGT4/ZNjOhigTAaDRoyXnpL9L0y32JsbDwMij5FhHLu1sEOCXa2xu6Y4yNKf2wNFcLN4bv2xmJdwn5EgYeEzU8WwWYMa88IXfxrlXGRdW3NLVvQzWZ9vxEOmgkTe6d7mSAWf3tGhB3mF1jPx3Podl02eWGmw0QnRX8OiewjjHIbtRJ+xkPMY0+DXKnsIo7pjE0iTWBCJQimzUDLnAvp4mJ1ww9marGoYm0JHw6wCRaLBiWMwpEtHUTMkMR1h+2LbZmNwhW+Plm67bPrx5hRXvAPReFZvFkNTe+nxluAyYhyLF9aZiXFy ryfiuwaf 2m1xMXOd+PMdlCUECa/8eVEIFOOiErDf/OE61YDyu4AhhiXoGEfTh1+Ba0X+D4TOOxSqrwFR7VoS49Mj4yOOjsdxxgjFCqMiNrSCMHYH20vKdOzAo2P/2MGjvlOPFSdcA0PigqS1JZGWjQ1F1W5sZiT3njLIOo9x8iB2fc2BvbLhTxniftijibVuQ36YbLPSdzWQLdX4M0/5C5Q09uKiVEEptbZL5AJHg4sKT1+qwJdZOVEI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001203, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: DAMON monitoring parameters including sampling and aggregation intervals should be tuned for given workloads. However, the fact is not explicitly documented. Also there is no official guide to help the tuning. This apparently confused a number of people[1] at best, or made people forgive DAMON without tuning. Add a guide on the design document. [1] https://lore.kernel.org/20241202175459.2005526-1-sj@kernel.org Signed-off-by: SeongJae Park --- Documentation/mm/damon/design.rst | 48 +++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index 667775bab86c..dd7e0f63a69a 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -203,6 +203,8 @@ This scheme, however, cannot preserve the quality of the output if the assumption is not guaranteed. +.. _damon_design_adaptive_regions_adjustment: + Adaptive Regions Adjustment ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -264,6 +266,52 @@ tracepoints. For more details, please refer to the documentations for respectively. +Monitoring Parameters Tuning Guide +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In short, set ``aggregation interval`` to capture meaningful amount of accesses +for the purpose. The amount of accesses can be measured using ``nr_accesses`` +and ``age`` of regions in the aggregated monitoring results snapshot. The +default value of the interval, ``100ms``, turns out to be too short in many +cases. Set ``sampling interval`` proportional to ``aggregation interval``. By +default, ``1/20`` is recommended as the ratio. + +``Aggregation interval`` should be set as the time interval that the workload +can make an amount of accesses for the monitoring purpose, within the interval. +If the interval is too short, only small number of accesses are captured. As a +result, the monitoring results look everything is samely accessed only rarely. +For many purposes, that would be useless. If it is too long, however, the time +to converge regions with the :ref:`regions adjustment mechanism +` can be too long, depending on the +time scale of the given purpose. This could happen if the workload is actually +making only rare accesses but the user thinks the amount of accesses for the +monitoring purpose too high. For such cases, the target amount of access to +capture per ``aggregation interval`` should carefully reconsidered. Also, note +that the captured amount of accesses is represented with not only +``nr_accesses``, but also ``age``. For example, even if every region on the +monitoring results show zero ``nr_accesses``, regions could still be +distinguished using ``age`` values as the recency information. + +Hence the optimum value of ``aggregation interval`` depends on the access +intensiveness of the workload. The user should tune the interval based on the +amount of access that captured on each aggregated snapshot of the monitoring +results. + +Note that the default value of the interval is 100 milliseconds, which is too +short in many cases, especially on large systems. + +``Sampling interval`` defines the resolution of each aggregation. If it is set +too large, monitoring results will look like every region was samely rarely +accessed, or samely frequently accessed. That is, regions become +undistinguishable based on access pattern, and therefore the results will be +useless in many use cases. If ``sampling interval`` is too small, it will not +degrade the resolution, but will increase the monitoring overhead. If it is +appropriate enough to provide a resolution of the monitoring results that +sufficient for the given purpose, it shouldn't be unnecessarily further +lowered. It is recommended to be set proportional to ``aggregation interval``. +By default, the ratio is set as ``1/20``, and it is still recommended. + + .. _damon_design_damos: Operation Schemes From patchwork Fri Jan 10 18:52:29 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 13935392 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 393BDE7719C for ; Fri, 10 Jan 2025 18:52:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 513EF6B00CD; Fri, 10 Jan 2025 13:52:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C1C48D000E; Fri, 10 Jan 2025 13:52:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3163C6B00CE; Fri, 10 Jan 2025 13:52:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 087048D000E for ; Fri, 10 Jan 2025 13:52:47 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B1EE71C7EA5 for ; Fri, 10 Jan 2025 18:52:46 +0000 (UTC) X-FDA: 82992438732.21.53A15A3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id 12F1040002 for ; Fri, 10 Jan 2025 18:52:44 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="C/7tOLDx"; spf=pass (imf04.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736535165; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=g3IZfFqaGGQvcHSADWPRt5ZyBkCabg2oxd++MrvQv7A=; b=1chh3Rsk8DYiXEgAyxtaC2MdBN75cE4XWTdwHuw19KIVcgt6ai295j5XKHhyhIoY+6+fk5 TIifUzuKMiGaqnFcsENDI66u7XmVmDj64nn+7uJ/RwhHlrt81MY+TD1JxNHrVWhgkl8Ggc HLJELa3cN3JJDbzmwc2tDsUOFGr7Es4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736535165; a=rsa-sha256; cv=none; b=3zgeZcAI6YmVkozAWca0rAeqzjf3eGoDTmQeJjDFsqhHxHYBS28lrnWnnne/0shYDpkVI5 54XoBrrUYsFZpMtKIndv3TM+NAirD5sv+qKHg4oZ3/+jhdyw0Ptq/U/0dYEOspftbuq3Ms 1A9YKUkyf/8LKKdXMtrc5E4n6A5T4fQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="C/7tOLDx"; spf=pass (imf04.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 5E4C1A428CB; Fri, 10 Jan 2025 18:50:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BC5DC4CED6; Fri, 10 Jan 2025 18:52:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736535162; bh=5Klw8hhvSx8PwTI5/pAo/3RzEAQ8x9KUOdqUhdvSuAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C/7tOLDxElbvtd88mHf2oqtpr6svMq043nME7utrlnA4j1Ty+czFMhdc3WHsgcoKK SM5CyK6FehUEStF2WgXnmS1rG2T4M93lUwNFcJV6TWD8SayQ2EEvvOrvXBiPcKUP4J SjH9h5wnZoVMNtk7qX6NscgHVmpr49MAYf3bLTkEBEskSmaGudQ9Q+ge6ZbvV1MDOK Y6E6pMJ2ofopymHf0b9nBmCiBAAPHYb7koCCxIUBmMUfoXLAp/tj4AssOZZsZcmRzd fydwnCWh5buqFh0nLiKxK2i9/GVNYwOy2ntM9G9GFURRwlahna8vSd4+R2DWlDD4qz AElWBPz8oeYfg== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Jonathan Corbet , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 2/5] Docs/mm/damon: add an example monitoring intervals tuning Date: Fri, 10 Jan 2025 10:52:29 -0800 Message-Id: <20250110185232.54907-3-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250110185232.54907-1-sj@kernel.org> References: <20250110185232.54907-1-sj@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 12F1040002 X-Stat-Signature: bybrdikwz6atdin69jbzjdhxssaw7c51 X-Rspam-User: X-HE-Tag: 1736535164-877925 X-HE-Meta: U2FsdGVkX1+EvF6xjQZPPdECtQvFZXGlDXvpdVfq4C8zpMm0K2jXZKM36noGmrAZdZNC0CqaJajv8JZgj1Oy1DaI9iTJ5Y8hArmUQgJ18F9pCsFPhUVQRm24gq9s/KBehhs75ol7EZsZIdWlXFuEC3aXquW+oAHCCVKzxaESLM/FlnXLfb4KT/wcvcBiPDn4RpxFEIxTKR3+xrsms8BvHT88Cz6WUYSLrLv2OjBc1v/u+oyjG88VszM/XZ25VrqWyq8G5ZEgCa1wFgmgOmOkv8nbXVynVMr9iiLzXKdolYp3eHlfnk0Pw7HF/V866+Iu7JaxvtC9bBanHdNBFnqsJbrkWJpsRE7YiJDbn9CBihBtotxrUkQIM3dcPzoHZzNKLoUMDNWSRxYDEtpMafMZ3uN9iJGizGRCyUgCY1atEDshA8pspXczOXnskCyjsgLVzH3L2MQ+0hIQyD64k1WqmY6Zw80cBb/XeaYtS3Mr2EeoK+1n7fASJezcw/OlfKFU2tyK8Icr3N4pVrGnGTRNOPnRx+dzrygF5Hh9/94+/2FHTOCqhFxuPWfL89fg6bsq7y8p6fUjpEVbjzZT3Lm0PhnKmK7cvC2FFI15fz1Fmy78tqG5B8DUtGbAAVdeTuw6+A2jGVWEVVZ2UKW3zdXRr7g5RHVz+SRUOcuYyuqYyYjkaxSJQ2Dkts1Q5fbm65M7V1wsxQLQ0HEDD/Yw5hlGLGll5FuMOX75jjS9KhSEh1We575AYShhO9XZ2y+gxDD4dEgE7NvCCSbzRRDW2MseBAPmB2wGzBieMFfeEfgCc6mfRGTIVqSti2K4FbtzPD0wsr3TZrgedeB52jfaAMzQBgGMBySXhS4CkWwOE6m1y21LrFZi7Q2L28twuDd/cI0fl/GUfD9gn20eB9DIa72qPek3o0ySxEO1Fk2It9iL5mCeBJ24sQX8Hem5pA0qQiuyIa5h0NsyXx7gikxLvNU YVm6TxU6 6rwpAjspLw5zqdQEe6v5gMfd+A8Se8Eq6itoc/P3mv4OKSoQLUJGZprb5lXj0muGUeh3pVju9yWXuRccIHS0cpgzPLj3JOE0953K9jR+xD7HooOrrNEUQu2jnASL8/rSQWxdiMeVR+wlWPS319QOnv513pH9hjQ3W7Uj/JH7ntO3y36XuCpykRh6rixucIhXnR1YGXJeKp2gTHd7uwurIu/cF3MWYcPFkWXGGiFxd5zHTKOZyk9pQVhqT59scYV8s2lgOwweF0Erm0mxj89C1IPhGT4lHyg1L88SeZamPLkpC/uY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Add a DAMON monitoring intervals tuning example that contains output from a demonstration of the guide on a real server workload system. The example with real world numbers will help users better understanding the guide instructions and what outputs they can expect and verify. Those will again help finding the rooms for improvements on the guide. Signed-off-by: SeongJae Park --- Documentation/mm/damon/design.rst | 9 + .../monitoring_intervals_tuning_example.rst | 247 ++++++++++++++++++ 2 files changed, 256 insertions(+) create mode 100644 Documentation/mm/damon/monitoring_intervals_tuning_example.rst diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index dd7e0f63a69a..e28c6a1b40ae 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -266,6 +266,8 @@ tracepoints. For more details, please refer to the documentations for respectively. +.. _damon_design_monitoring_params_tuning_guide: + Monitoring Parameters Tuning Guide ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -311,6 +313,13 @@ sufficient for the given purpose, it shouldn't be unnecessarily further lowered. It is recommended to be set proportional to ``aggregation interval``. By default, the ratio is set as ``1/20``, and it is still recommended. +Refer to below documents for an example tuning based on the above guide. + +.. toctree:: + :maxdepth: 1 + + monitoring_intervals_tuning_example + .. _damon_design_damos: diff --git a/Documentation/mm/damon/monitoring_intervals_tuning_example.rst b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst new file mode 100644 index 000000000000..334a854efb40 --- /dev/null +++ b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst @@ -0,0 +1,247 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================= +DAMON Moniting Interval Parameters Tuning Example +================================================= + +DAMON's monitoring parameters need tuning based on given workload and the +monitoring purpose. There is a :ref:`tuning guide +` for that. This document +provides an example tuning based on the guide. + +Setup +===== + +For below example, DAMON of Linux kernel v6.11 and `damo +`_ (DAMON user-space tool) v2.5.9 was used to +monitor and visualize access patterns on the physical address space of a system +running a real-world server workload. + +5ms/100ms intervals: Too Short Interval +======================================= + +Let's start by capturing the access pattern snapshot on the physical address +space of the system using DAMON, with the default interval parameters (5 +milliseconds and 100 milliseconds for the sampling and the aggregation +intervals, respectively). Wait ten minutes between the start of DAMON and +the capturing of the snapshot, to show a meaningful time-wise access patterns. +:: + + # damo start + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + +Then, list the DAMON-found regions of different access patterns, sorted by the +"access temperature". "Access temperature" is a metric representing the +access-hotness of a region. It is calculated as a weighted sum of the access +frequency and the age of the region. If the access frequency is 0 %, the +temperature is multipled by minus one. That is, if a region is not accessed, +it gets minus temperature and it gets lower as not accessed for longer time. +The sorting is in temperature-ascendint order, so the region at the top of the +list is the coldest, and the one at the bottom is the hottest one. :: + + # damo report access --sort_regions_by temperature + 0 addr 16.052 GiB size 5.985 GiB access 0 % age 5.900 s # coldest + 1 addr 22.037 GiB size 6.029 GiB access 0 % age 5.300 s + 2 addr 28.065 GiB size 6.045 GiB access 0 % age 5.200 s + 3 addr 10.069 GiB size 5.983 GiB access 0 % age 4.500 s + 4 addr 4.000 GiB size 6.069 GiB access 0 % age 4.400 s + 5 addr 62.008 GiB size 3.992 GiB access 0 % age 3.700 s + 6 addr 56.795 GiB size 5.213 GiB access 0 % age 3.300 s + 7 addr 39.393 GiB size 6.096 GiB access 0 % age 2.800 s + 8 addr 50.782 GiB size 6.012 GiB access 0 % age 2.800 s + 9 addr 34.111 GiB size 5.282 GiB access 0 % age 2.300 s + 10 addr 45.489 GiB size 5.293 GiB access 0 % age 1.800 s # hottest + total size: 62.000 GiB + +The list shows not seemingly hot regions, and only minimum access pattern +diversity. Every region has zero access frequency. The number of region is +10, which is the default ``min_nr_regions value``. Size of each region is also +nearly idential. We can suspect this is because “adaptive regions adjustment” +mechanism was not well working. As the guide suggested, we can get relative +hotness of regions using ``age`` as the recency information. That would be +better than nothing, but given the fact that the longest age is only about 6 +seconds while we waited about ten minuts, it is unclear how useful this will +be. + +The temperature ranges to total size of regions of each range histogram +visualization of the results also shows no interesting distribution pattern. :: + + # damo report access --style temperature-sz-hist + + [-,590,000,000, -,549,000,000) 5.985 GiB |********** | + [-,549,000,000, -,508,000,000) 12.074 GiB |********************| + [-,508,000,000, -,467,000,000) 0 B | | + [-,467,000,000, -,426,000,000) 12.052 GiB |********************| + [-,426,000,000, -,385,000,000) 0 B | | + [-,385,000,000, -,344,000,000) 3.992 GiB |******* | + [-,344,000,000, -,303,000,000) 5.213 GiB |********* | + [-,303,000,000, -,262,000,000) 12.109 GiB |********************| + [-,262,000,000, -,221,000,000) 5.282 GiB |********* | + [-,221,000,000, -,180,000,000) 0 B | | + [-,180,000,000, -,139,000,000) 5.293 GiB |********* | + total size: 62.000 GiB + +In short, the parameters provide poor quality monitoring results for hot +regions detection. According to the :ref:`guide +`, this is due to the too short +aggregation interval. + +100ms/2s intervals: Starts Showing Small Hot Regions +==================================================== + +Following the guide, increase the interval 20 times (100 milliseocnds and 2 +seconds for sampling and aggregation intervals, respectively). :: + + # damo start -s 100ms -a 2s + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + # damo report access --sort_regions_by temperature + 0 addr 10.180 GiB size 6.117 GiB access 0 % age 7 m 8 s # coldest + 1 addr 49.275 GiB size 6.195 GiB access 0 % age 6 m 14 s + 2 addr 62.421 GiB size 3.579 GiB access 0 % age 6 m 4 s + 3 addr 40.154 GiB size 6.127 GiB access 0 % age 5 m 40 s + 4 addr 16.296 GiB size 6.182 GiB access 0 % age 5 m 32 s + 5 addr 34.254 GiB size 5.899 GiB access 0 % age 5 m 24 s + 6 addr 46.281 GiB size 2.995 GiB access 0 % age 5 m 20 s + 7 addr 28.420 GiB size 5.835 GiB access 0 % age 5 m 6 s + 8 addr 4.000 GiB size 6.180 GiB access 0 % age 4 m 16 s + 9 addr 22.478 GiB size 5.942 GiB access 0 % age 3 m 58 s + 10 addr 55.470 GiB size 915.645 MiB access 0 % age 3 m 6 s + 11 addr 56.364 GiB size 6.056 GiB access 0 % age 2 m 8 s + 12 addr 56.364 GiB size 4.000 KiB access 95 % age 16 s + 13 addr 49.275 GiB size 4.000 KiB access 100 % age 8 m 24 s # hottest + total size: 62.000 GiB + # damo report access --style temperature-sz-hist + + [-42,800,000,000, -33,479,999,000) 22.018 GiB |***************** | + [-33,479,999,000, -24,159,998,000) 27.090 GiB |********************| + [-24,159,998,000, -14,839,997,000) 6.836 GiB |****** | + [-14,839,997,000, -5,519,996,000) 6.056 GiB |***** | + [-5,519,996,000, 3,800,005,000) 4.000 KiB |* | + [3,800,005,000, 13,120,006,000) 0 B | | + [13,120,006,000, 22,440,007,000) 0 B | | + [22,440,007,000, 31,760,008,000) 0 B | | + [31,760,008,000, 41,080,009,000) 0 B | | + [41,080,009,000, 50,400,010,000) 0 B | | + [50,400,010,000, 59,720,011,000) 4.000 KiB |* | + total size: 62.000 GiB + +DAMON found two distinct 4 KiB regions that pretty hot. The regions are also +well aged. The hottest 4 KiB region was keeping the access frequency for about +8 minutes, and the coldest region was keeping no access for about 7 minutes. +The distribution on the histogram also looks like having a pattern. + +Especially, the finding of the 4 KiB regions among the 62 GiB total memory +shows DAMON’s adaptive regions adjustment is working as designed. + +Still the number of regions is close to the ``min_nr_regions``, and sizes of +cold regions are similar, though. Apparently it is improved, but it still has +rooms to improve. + +400ms/8s intervals: Pretty Improved Results +=========================================== + +Increase the intervals four times (400 milliseconds and 8 seconds +for sampling and aggregation intervals, respectively). :: + + # damo start -s 400ms -a 8s + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + # damo report access --sort_regions_by temperature + 0 addr 64.492 GiB size 1.508 GiB access 0 % age 6 m 48 s # coldest + 1 addr 21.749 GiB size 5.674 GiB access 0 % age 6 m 8 s + 2 addr 27.422 GiB size 5.801 GiB access 0 % age 6 m + 3 addr 49.431 GiB size 8.675 GiB access 0 % age 5 m 28 s + 4 addr 33.223 GiB size 5.645 GiB access 0 % age 5 m 12 s + 5 addr 58.321 GiB size 6.170 GiB access 0 % age 5 m 4 s + [...] + 25 addr 6.615 GiB size 297.531 MiB access 15 % age 0 ns + 26 addr 9.513 GiB size 12.000 KiB access 20 % age 0 ns + 27 addr 9.511 GiB size 108.000 KiB access 25 % age 0 ns + 28 addr 9.513 GiB size 20.000 KiB access 25 % age 0 ns + 29 addr 9.511 GiB size 12.000 KiB access 30 % age 0 ns + 30 addr 9.520 GiB size 4.000 KiB access 40 % age 0 ns + [...] + 41 addr 9.520 GiB size 4.000 KiB access 80 % age 56 s + 42 addr 9.511 GiB size 12.000 KiB access 100 % age 6 m 16 s + 43 addr 58.321 GiB size 4.000 KiB access 100 % age 6 m 24 s + 44 addr 9.512 GiB size 4.000 KiB access 100 % age 6 m 48 s + 45 addr 58.106 GiB size 4.000 KiB access 100 % age 6 m 48 s # hottest + total size: 62.000 GiB + # damo report access --style temperature-sz-hist + + [-40,800,000,000, -32,639,999,000) 21.657 GiB |********************| + [-32,639,999,000, -24,479,998,000) 17.938 GiB |***************** | + [-24,479,998,000, -16,319,997,000) 16.885 GiB |**************** | + [-16,319,997,000, -8,159,996,000) 586.879 MiB |* | + [-8,159,996,000, 5,000) 4.946 GiB |***** | + [5,000, 8,160,006,000) 260.000 KiB |* | + [8,160,006,000, 16,320,007,000) 0 B | | + [16,320,007,000, 24,480,008,000) 0 B | | + [24,480,008,000, 32,640,009,000) 0 B | | + [32,640,009,000, 40,800,010,000) 16.000 KiB |* | + [40,800,010,000, 48,960,011,000) 8.000 KiB |* | + total size: 62.000 GiB + +The number of regions having different access patterns has significantly +increased. Size of each region is also more varied. Total size of non-zero +access frequency regions is also significantly increased. Maybe this is already +good enough to make some meaningful memory management efficieny changes. + +800ms/16s intervals: Another bias +================================= + +Further double the intervals (800 milliseconds and 16 seconds for sampling +and aggregation intervals, respectively). The results is more improved for the +hot regions detection, but starts looking degrading cold regions detection. :: + + # damo start -s 800ms -a 16s + # sleep 600 + # damo record --snapshot 0 1 + # damo stop + # damo report access --sort_regions_by temperature + 0 addr 64.781 GiB size 1.219 GiB access 0 % age 4 m 48 s + 1 addr 24.505 GiB size 2.475 GiB access 0 % age 4 m 16 s + 2 addr 26.980 GiB size 504.273 MiB access 0 % age 4 m + 3 addr 29.443 GiB size 2.462 GiB access 0 % age 4 m + 4 addr 37.264 GiB size 5.645 GiB access 0 % age 4 m + 5 addr 31.905 GiB size 5.359 GiB access 0 % age 3 m 44 s + [...] + 20 addr 8.711 GiB size 40.000 KiB access 5 % age 2 m 40 s + 21 addr 27.473 GiB size 1.970 GiB access 5 % age 4 m + 22 addr 48.185 GiB size 4.625 GiB access 5 % age 4 m + 23 addr 47.304 GiB size 902.117 MiB access 10 % age 4 m + 24 addr 8.711 GiB size 4.000 KiB access 100 % age 4 m + 25 addr 20.793 GiB size 3.713 GiB access 5 % age 4 m 16 s + 26 addr 8.773 GiB size 4.000 KiB access 100 % age 4 m 16 s + total size: 62.000 GiB + # damo report access --style temperature-sz-hist + + [-28,800,000,000, -23,359,999,000) 12.294 GiB |***************** | + [-23,359,999,000, -17,919,998,000) 9.753 GiB |************* | + [-17,919,998,000, -12,479,997,000) 15.131 GiB |********************| + [-12,479,997,000, -7,039,996,000) 0 B | | + [-7,039,996,000, -1,599,995,000) 7.506 GiB |********** | + [-1,599,995,000, 3,840,006,000) 6.127 GiB |********* | + [3,840,006,000, 9,280,007,000) 0 B | | + [9,280,007,000, 14,720,008,000) 136.000 KiB |* | + [14,720,008,000, 20,160,009,000) 40.000 KiB |* | + [20,160,009,000, 25,600,010,000) 11.188 GiB |*************** | + [25,600,010,000, 31,040,011,000) 4.000 KiB |* | + total size: 62.000 GiB + +It found more non-zero access frequency regions. The number of regions is still +much higher than the ``min_nr_regions``, but it is reduced from that of the +previous setup. And apparently the distribution seems bit biased to hot +regions. + +Conclusion +========== + +With the above experimental tuning results, we can conclude the theory and the +guide makes sense to at least this workload, and could be applied to similar +cases. From patchwork Fri Jan 10 18:52:30 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 13935391 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8340AE77188 for ; Fri, 10 Jan 2025 18:52:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D76B08D000D; Fri, 10 Jan 2025 13:52:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D25B96B00CE; Fri, 10 Jan 2025 13:52:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA1028D000D; Fri, 10 Jan 2025 13:52:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 97F266B00CD for ; Fri, 10 Jan 2025 13:52:46 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6361FAEC25 for ; Fri, 10 Jan 2025 18:52:46 +0000 (UTC) X-FDA: 82992438732.12.170B9EC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id B50B6100010 for ; Fri, 10 Jan 2025 18:52:44 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="CZOUza/j"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736535164; a=rsa-sha256; cv=none; b=099KM85yJwP5/zrn4JlR19XiSabv55Tj8xNfZpmH3BQuHiWgOODK3dQfDT7QLdR7rFagmw G1bEGZtaoXp5matyGJbtQzGdyHZk0ik6FgV7mUqNn9ppHAqSG+g0DyjdZ//0jcNyidVEjO LGyyQIE1WzRIhXnvhuXu8eG5Q/LVAk4= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="CZOUza/j"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736535164; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zO3WhYXCz2vRIuWfey6mJ9EmuSnLmRAVX3MjZbqG2zM=; b=gscJHse2efoKflQZwSCLHSAFYLV6sKkJUOSczSp1Y9v66pPfwHf3HFoXKkyLApzYr0Xmrr Ghy4+U+cIhLhnvx7xRtjwsmgNjnyedxpvI9OLB/+Y1Z+ywcgSLKNVAfbX2OjSNS4jirXa2 zg5wwWcLP4Vd03QbCdeDTnG3WEKoYwY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DA9985C2F55; Fri, 10 Jan 2025 18:52:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62E3DC4CED6; Fri, 10 Jan 2025 18:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736535163; bh=aQ+Bj2xTqVO3IMkQIcaZrOE0PN1bTM2On8Eb95tnIgI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CZOUza/juB/9t158ZUTYhyyXOlW+YWK8xda7ymc4LKhaB9KtBHAivnNhE7IxMe5Yn 9lbrtz83aZRFa8hkMUDOPbHyK57Liq/PQqHumsTR5FHTEfHKC0BcGZ3pJM94WmNYRY 3Zxm61uBPNoIaxDaNwc7CsldDmTTxPmwv8Qe1MCZERKqvLni4ANNMfHA5NmD8Y4gU1 CUCbCYeSJ5f4TMVDJll6uW1pX5XDTXCkf/Td+PWgsh+KebQWF2zhUmYEvo639aHdwB PGFOyk7yPoFaO9OUaeC2rdsdfezAzUY2xOxQAteQKMTG60YshYar4DwD563v+OF4kt dveLIVntFFbOA== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Jonathan Corbet , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 3/5] Docs/admin-guide/mm/damon/usage: fix and add missing DAMOS filter sysfs files on files hierarchy Date: Fri, 10 Jan 2025 10:52:30 -0800 Message-Id: <20250110185232.54907-4-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250110185232.54907-1-sj@kernel.org> References: <20250110185232.54907-1-sj@kernel.org> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B50B6100010 X-Stat-Signature: 6u81ss4fryqf4ytp94nwon6ymqniktn4 X-HE-Tag: 1736535164-695655 X-HE-Meta: U2FsdGVkX1+e6F0umZA40ab/uXGHOmkeb6Btd7HI8ZWgbXSuuxb0A9TyrsOGW3OFR/UrFOxsKCSawtKpqnsZr/L5uLe+XTg9jmlYDSEvqW4AIIA94XUzyCZI5qcF0XjuA9n2zTwpcH5s9GamVio0bj4xcgZdGFljRUD/3jWYCNaNmwVtipUo+E8HL24vrtWSDTEsFtP0bc8FpklfUUF8RDvyRpzaNQC/P61UeHxpb2X4yzE9Xix6tCHYn0pai42HbaT9ioDkFcAGMWzRrD+INVqXKUWeFFKvnBAUuAayEDtZYZhC/X5OHlH1iEESCgeRz+PLP7dtv4jV3cMZKjLf2L0pOiGasV7o1sqrunRxXDVck8K7j0njasSAzj3oRgDpDCB0l1VNyJI/hIocWsmj/1mOxVtJCL2fa5hCbYpPnsdal4nx4PCdk1KUlVqa8ga6Z0IbwjsQJtnJ3il+9vx6P7WPmHBJNKsBtomQfbAalEeqm6bShq+Ydcqff3LpTnedQGbnfGbNVuCAV99mt5RKVLRjplg62azhewLGQBmuos8m6ycnRqAry0/OrSMRb2UCMhCI/vJ+Puja243j5fXZKPHv22LU3gqpyuRJSo99smx8W96CO3j8lpjwqiU4uvxjU0i6ZAkOkmFYTzMeshOwh0yl4M4CN5ia/Uth8BX4fu3LISPdBZo1wd+ZnLOoKL0ruAiekU0Xn/FY36rvq9nZOUfxffNiMctAQQYGWDe9gJ2BUdK6UYiR0KlmotmkGbetxVUpl8q2rK50CD6zmzbF9lRkwp/z2jqNDFeJ1EvArClFnkIJ65CPGlQmjVg/6rb4kuOtRY+WyT4PeCc6FLNWj1ZAlJ+LV6akJBs6PK2gRaZzaBfrsDfJ6kvRm47cikhmBhAf538NCnd0aUGNcGpchpc1hCD99L2lnSPmTSnb2bdh9sM0y6AGjMGS75B1OQdAJMcid8pBaMlNRgC6veC xzu9M+Qt 2WzZJ3SOOAQ3+hxRczWVQqWZbgPAAZrfn/BsKZI0u3F7fbRioONOBKjfxxueBN0vrnybiP+En8FFUsGaBsihYKItptjyzqiiW3dJxpfp3MTJYs3bqNHlsmjMAmf8z77zM+W0zlXJM7t8/fkKpValwk32KLV+5wqyYHWded7vr1WaGirK/FLunb7wOJ3wK2zNkNHHHxMPTzrxorhBgWXu+bw+QQCIKm1D0KmJ4VYEw0uSdqPtClxuMutSLMpxvQDUhbTBzJ+A8QZVSCgjeuaEMJ+fmUcCwIPQh9a5qC/iWFIxkMYA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: DAMOS filter directory part of DAMON sysfs files hierarchy on the usage document is wrong. 'memcg_path' file under the directory is wrongly written as 'memcg_id'. Also the directory has 'addr_start', 'addr_end', and 'target_idx' files, but the list is missing those. Fix the wrong name and add missing files. Signed-off-by: SeongJae Park --- Documentation/admin-guide/mm/damon/usage.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index f0d0c20711d6..47a44bd348ab 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -83,7 +83,7 @@ comma (","). │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value │ │ │ │ │ │ │ :ref:`watermarks `/metric,interval_us,high,mid,low │ │ │ │ │ │ │ :ref:`filters `/nr_filters - │ │ │ │ │ │ │ │ 0/type,matching,memcg_id,allow + │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx │ │ │ │ │ │ │ :ref:`stats `/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds │ │ │ │ │ │ │ :ref:`tried_regions `/total_bytes │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed From patchwork Fri Jan 10 18:52:31 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 13935393 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6FEDE77188 for ; Fri, 10 Jan 2025 18:52:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8DA28D000F; Fri, 10 Jan 2025 13:52:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C17748D000E; Fri, 10 Jan 2025 13:52:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB4408D000F; Fri, 10 Jan 2025 13:52:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8C7AB8D000E for ; Fri, 10 Jan 2025 13:52:47 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 428AE140E2D for ; Fri, 10 Jan 2025 18:52:47 +0000 (UTC) X-FDA: 82992438774.08.BD0F9A8 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf28.hostedemail.com (Postfix) with ESMTP id A9D52C0012 for ; Fri, 10 Jan 2025 18:52:45 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lMNKBENO; spf=pass (imf28.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736535165; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/xHzKxdITLq9amvEiKJe8fX+MXHuR8Y5SH25DLls5vM=; b=P2Is6tqFCKYzRYWv7xUROiGve41uGPIMh1I+dXVjIC4j/bUcLBN4EmUoNitb38A4inenDv bDc89UGmMaEfBhnasKuLYJsInXnbGDimx3rfmiKD22FvHVVKhUn2JmlzJo+XQqwgxu1CVA 8EwqymcP5LSEnzTO5afzFd36obS+cd8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736535165; a=rsa-sha256; cv=none; b=c/aXcwLE1TEabvfTIqn+fYyJOzreLG5Jdnm2144IJTgWXLQ1gTdm/aRzZcpivDxYJZihx0 fzCoMd9rGVinRNgBOl/6k/pX5dVRWUAAvqFLlKMn38GsPLNDBBG8AJ72pSlKWzjHvD2Kxp D9WiFIexuJeoe1Yp1GC8vqT6/ryclA8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lMNKBENO; spf=pass (imf28.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 87D3BA428D0; Fri, 10 Jan 2025 18:50:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78C0EC4CED6; Fri, 10 Jan 2025 18:52:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736535164; bh=ew5XgI3zhdST5X2UaL5ouhohLppujWeUu4n87xwMgTs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lMNKBENOmMQzlS+PAUYCNfYlNbOmaFYkeYcwNC3a6R18W7BN6tuZJBOqu0SpfjYKo pq0OwD4oZqBYWcENh+fgMWlWwbHxAe6diuDG/DE5UI7VNxS5U5lePu8X13ZtVHCCiT xhA+/EZdpAWjLjWHsHQFIIHkBKRowHFq6lwhpq/2ZhS/Q30SeL7hgB3kf31yPCVYxB yIWOmS/seNziAb6R9XN+SGFRXJTujhH0IS9PJrdhtTNMZswONEludKyEvJjBxi/h/0 DGqlbBU6TqWzOupor6LhgMiedHBCRNCRegZMl+iemLT/yKtv+snuFl9GHFjoWANDlU U7rpWdkkCsH0g== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Jonathan Corbet , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 4/5] Docs/admin-guide/mm/damon/start: update snapshot example Date: Fri, 10 Jan 2025 10:52:31 -0800 Message-Id: <20250110185232.54907-5-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250110185232.54907-1-sj@kernel.org> References: <20250110185232.54907-1-sj@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A9D52C0012 X-Stat-Signature: po4awa59qychpommfk5zbe7tbck1gixc X-Rspam-User: X-HE-Tag: 1736535165-533701 X-HE-Meta: U2FsdGVkX1/H9glnk0D70ozouLO6ieuj+I6/v6YN/C6qugG1jyKih3VF7sApOVsAySTp2L3H02hYbSsCEwjKY3nZx2s1eWnQlqE3b8wRnEkL85di/jYB+4W+qm1wU6H4pMzMonsQmJl5yY6N3E+pzZXeTcsdeknLp2vG8uZX6yvbtyUvY5vXRMCWpb//5O2S/0F3SDlzQxOAyzVjzif+Qmk0aszZYzpNGEBpxI9t908ehEOTImDZ4H44S4QEfU3XYu8/N2+sNSUazOARq3t5gK7qqYEO5MAf2SvoMgBOGGQSU+CNzvAUN9XRvhy+rB5OwIU0tLhS4gAEiFfh1wHRzraD/TUrsnU2fTvX5vBNx8GaOM1/bSn6vaJcQd9BJjyY8qpeZyqvp34evVL63nQlwNrPOC5hTE1l8nWQHgs1ohp0ETn5SqnZ6AZyMA2yReBbq7yMC1fiZVlOVrTrTpdyaxIC+9rPzfnI2MVqigkXpVLUPJgZQkRrJkHqBQtqJvQ4/sZhbde+xQ2v69GxVa+ILqkbQEDDOPm5DXyN+GSZRmUr+sUCwn2J5GKfselXRU4QBeG0vnYdax9rAzeYBp1MiL35U9uxuQOs4zgRFgIrkN3UYWivWAebtn1AW4XHSEPTrdA9MeE4tN1lBxoScQVOhhLdDE/HWW3AEutE92ihbBoczIqlVUQPy/hM+N70EjTphJbvwtjYNB47gao6UOVWNGMsOHxJj1dqbcS2+db+3YVI68Davuaw4/HI/WbDStqu5gSVMvnmq4MXX2So8yRmnHc2McF1ndJ/YXWWovm0KeyduqT31zRyvNH1DU73Af97Q8uVaDgRQYB9SYehh/aRKSQD2godeSCQUd9JEUji1QRAYBLOgHWvAT76T+JlOW/zbq7YLeSeSeEOcHQhcNfVOU7V/HdwXr/7FffDxtR/TvBnMuS/CAvH+VJWt8o5xqi0787aPciPKGP3mTrcukL imZSDoZ2 yTRQMRuLp/ia0hjRCBzJSkQ3Kb/eN9A4zF3WbSCIY98bevTspGiGF+EH3bviAFGcC7SswTonTTHYYuXKXzknUMp0fM9TPiZZUWnrefNf9OyUF0YPNyGmWzT5TuANMtSCpYk9X054KDKHAgfQ8XGxaWa/XqnAmRVNKSWoHS/Q1ZWoWVdX7cOl5D/37vNGvPix2ixYhRWQnYllXLDOAEQwIxGZHpuAvGFL0rzj52B8OpbkaOgaumBBIBUI8JosT6yChAcoZ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Two of DAMON user-space tool (damo) commands that are used for examples on DAMON getting started document, namely 'damo show' and 'damo report heats' are deprecated[1,2], and replaced by new commands that provides same functions with unified and simplified user interfaces. Also the example output of 'damo show' is outdated. 'damo schemes' command is not deprecated, but users are recommended to use 'damo start' or 'damo tune' instead. Update the examples to use the replacements, recommdnations, and up-to-date output formats. [1] https://git.kernel.org/sj/damo/c/3272e0ac94ecc5e1 [2] https://git.kernel.org/sj/damo/c/da3ec66bbdd9e87d Signed-off-by: SeongJae Park --- Documentation/admin-guide/mm/damon/start.rst | 67 ++++++++++++-------- 1 file changed, 40 insertions(+), 27 deletions(-) diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst index c4dddf6733cd..ede14b679d02 100644 --- a/Documentation/admin-guide/mm/damon/start.rst +++ b/Documentation/admin-guide/mm/damon/start.rst @@ -42,32 +42,45 @@ the execution. :: $ git clone https://github.com/sjp38/masim; cd masim; make $ sudo damo start "./masim ./configs/stairs.cfg --quiet" - $ sudo ./damo show - 0 addr [85.541 TiB , 85.541 TiB ) (57.707 MiB ) access 0 % age 10.400 s - 1 addr [85.541 TiB , 85.542 TiB ) (413.285 MiB) access 0 % age 11.400 s - 2 addr [127.649 TiB , 127.649 TiB) (57.500 MiB ) access 0 % age 1.600 s - 3 addr [127.649 TiB , 127.649 TiB) (32.500 MiB ) access 0 % age 500 ms - 4 addr [127.649 TiB , 127.649 TiB) (9.535 MiB ) access 100 % age 300 ms - 5 addr [127.649 TiB , 127.649 TiB) (8.000 KiB ) access 60 % age 0 ns - 6 addr [127.649 TiB , 127.649 TiB) (6.926 MiB ) access 0 % age 1 s - 7 addr [127.998 TiB , 127.998 TiB) (120.000 KiB) access 0 % age 11.100 s - 8 addr [127.998 TiB , 127.998 TiB) (8.000 KiB ) access 40 % age 100 ms - 9 addr [127.998 TiB , 127.998 TiB) (4.000 KiB ) access 0 % age 11 s - total size: 577.590 MiB - $ sudo ./damo stop + $ sudo damo report access + heatmap: 641111111000000000000000000000000000000000000000000000[...]33333333333333335557984444[...]7 + # min/max temperatures: -1,840,000,000, 370,010,000, column size: 3.925 MiB + 0 addr 86.182 TiB size 8.000 KiB access 0 % age 14.900 s + 1 addr 86.182 TiB size 8.000 KiB access 60 % age 0 ns + 2 addr 86.182 TiB size 3.422 MiB access 0 % age 4.100 s + 3 addr 86.182 TiB size 2.004 MiB access 95 % age 2.200 s + 4 addr 86.182 TiB size 29.688 MiB access 0 % age 14.100 s + 5 addr 86.182 TiB size 29.516 MiB access 0 % age 16.700 s + 6 addr 86.182 TiB size 29.633 MiB access 0 % age 17.900 s + 7 addr 86.182 TiB size 117.652 MiB access 0 % age 18.400 s + 8 addr 126.990 TiB size 62.332 MiB access 0 % age 9.500 s + 9 addr 126.990 TiB size 13.980 MiB access 0 % age 5.200 s + 10 addr 126.990 TiB size 9.539 MiB access 100 % age 3.700 s + 11 addr 126.990 TiB size 16.098 MiB access 0 % age 6.400 s + 12 addr 127.987 TiB size 132.000 KiB access 0 % age 2.900 s + total size: 314.008 MiB + $ sudo damo stop The first command of the above example downloads and builds an artificial memory access generator program called ``masim``. The second command asks DAMO -to execute the artificial generator process start via the given command and -make DAMON monitors the generator process. The third command retrieves the -current snapshot of the monitored access pattern of the process from DAMON and -shows the pattern in a human readable format. - -Each line of the output shows which virtual address range (``addr [XX, XX)``) -of the process is how frequently (``access XX %``) accessed for how long time -(``age XX``). For example, the fifth region of ~9 MiB size is being most -frequently accessed for last 300 milliseconds. Finally, the fourth command -stops DAMON. +to start the program via the given command and make DAMON monitors the newly +started process. The third command retrieves the current snapshot of the +monitored access pattern of the process from DAMON and shows the pattern in a +human readable format. + +The first line of the output shows the relative access temperature (hotness) of +the regions in a single row hetmap format. Each column on the heatmap +represents regions of same size on the monitored virtual address space. The +position of the colun on the row and the number on the column represents the +relative location and access temperature of the region. ``[...]`` means +unmapped huge regions on the virtual address spaces. The second line shows +additional information for better understanding the heatmap. + +Each line of the output from the third line shows which virtual address range +(``addr XX size XX``) of the process is how frequently (``access XX %``) +accessed for how long time (``age XX``). For example, the evelenth region of +~9.5 MiB size is being most frequently accessed for last 3.7 seconds. Finally, +the fourth command stops DAMON. Note that DAMON can monitor not only virtual address spaces but multiple types of address spaces including the physical address space. @@ -95,7 +108,7 @@ Visualizing Recorded Patterns You can visualize the pattern in a heatmap, showing which memory region (x-axis) got accessed when (y-axis) and how frequently (number).:: - $ sudo damo report heats --heatmap stdout + $ sudo damo report heatmap 22222222222222222222222222222222222222211111111111111111111111111111111111111100 44444444444444444444444444444444444444434444444444444444444444444444444444443200 44444444444444444444444444444444444444433444444444444444444444444444444444444200 @@ -160,6 +173,6 @@ Data Access Pattern Aware Memory Management Below command makes every memory region of size >=4K that has not accessed for >=60 seconds in your workload to be swapped out. :: - $ sudo damo schemes --damos_access_rate 0 0 --damos_sz_region 4K max \ - --damos_age 60s max --damos_action pageout \ - + $ sudo damo start --damos_access_rate 0 0 --damos_sz_region 4K max \ + --damos_age 60s max --damos_action pageout \ + From patchwork Fri Jan 10 18:52:32 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 13935394 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74C2FE7719C for ; Fri, 10 Jan 2025 18:52:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFC158D0010; Fri, 10 Jan 2025 13:52:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EABB18D000E; Fri, 10 Jan 2025 13:52:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C88D68D0010; Fri, 10 Jan 2025 13:52:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A3FAF8D000E for ; Fri, 10 Jan 2025 13:52:48 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 693EA80E16 for ; Fri, 10 Jan 2025 18:52:48 +0000 (UTC) X-FDA: 82992438816.26.48818DA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id D05D5140011 for ; Fri, 10 Jan 2025 18:52:46 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nOJStIW3; spf=pass (imf09.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736535166; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SaaWyyv8li+dteHijC7o/yJUzsQm0EvRgS8tQ52mNqc=; b=6GzW3HaV3X2tjv7hdI/+7meBE+ypggi37a6tMJ0ZoV5Vm0po4QMWwnGwlegACcsEmCA574 eRBrBF+xNJ9vjPrtfumUF8CRZH20VJruh2xJOHUIi5d67PFXW0wHkHyYnaYgjqEAkHIijV gjPp7oeHg5wmNJzuGt8mwg7+uCKiTAk= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nOJStIW3; spf=pass (imf09.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736535166; a=rsa-sha256; cv=none; b=VT5ZGwVoBQlN7CEjSGXre7DaoOpJRrVszT8Y14PP8vMkvst2CbPPgPwWhIbcFbt8lvdO0i MEx42So8Moadwo/EOhkOSTPbO77WlLCvbXDFK2A7Gb+YbStK69RdBvW2VJQYKz4LfYJxFu 6ySmTg0AHrTbojbdxDvYL3glbqyGFIA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 213BD5C5690; Fri, 10 Jan 2025 18:52:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E14BC4CED6; Fri, 10 Jan 2025 18:52:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736535165; bh=cNUCy0TlSD/d2Pmdsrm3XmKc2hpQgSkhrpqQ3/ahDso=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nOJStIW36CNd5fyaROhH7XAA105UoPMXTv3X5+3gEdRxdL8roGa7Udmi7qjQ091Vh 10qDvazBoYzxsVrclJ/LLeGyN5fLO6pW/zOd3W9bZ8BXBLdw5qitUDZIKi9w0ydLZS 5u8jraLrBtSVYRe87G2EB0o28LyTX7sqb3hUNfVBJDYUFiAORjeQKEu0OG0wwXHmyv 0A7iUOtXZZMhDLQym8FXdIRcj2XKwQi+ZvfDC84+gvcn/spWfckXIj8DU5JTvHTyqg kE78jbwpINmyDpsOIudJNDFxrpQHyaZaVnZkNwQkpiLPjjXEIR8CKQ2f8ksWky8oI8 QAkSwCkBs4ooA== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yunjeong Mun , Honggyu Kim Subject: [PATCH 5/5] mm/damon: explain "effective quota" on kernel-doc comment Date: Fri, 10 Jan 2025 10:52:32 -0800 Message-Id: <20250110185232.54907-6-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250110185232.54907-1-sj@kernel.org> References: <20250110185232.54907-1-sj@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam05 X-Stat-Signature: uheknxbudrguoq18m1dzesgycdhbo5bh X-Rspamd-Queue-Id: D05D5140011 X-Rspam-User: X-HE-Tag: 1736535166-527695 X-HE-Meta: U2FsdGVkX1+ncfiFd98tK8AOf4jYdOrkrQ1nS3H11+WPYS1rWZ6pUL8GDYCuxoyfYYuJPHlZ+ML7J2neiXdDlyrTfvqhp0AfP3dmeh47GZ+MU2uEvZ9SZ66+z6sK25J65/E0sn+zpBiiZ0VEY8Kz7cIdynOzHFUbuRUpHCHTBdLNUg36ZRr9kMyBmdz8jAPZoBUPQ+dTOGMfI7xLPdfCV6qfBuE/wP1M+1CWIo5Tk7TG4rdM0/v9CQ2QUHZDEsV/0aCZ7fzV+1N+y6GGcdN/7a+WYC/+Di/NJzXzqpaheSxkTPNhmZLCQtRPGYYg6er8+zaW0cPin8uvbCniStsB6Iw51jgYPYzhczfALZQ25EUN7uCST10UO51y1+7govzkfP0JggK0XmWo5fr9JWWCaEh3wbkF9ekK4MI5bBilM/zzNYsZiO4ITM935Ejsto3VWUOm5hfaNA24dEalcQQp0fIn76qQpjD4kdxXz21d/5CfjulOBHji5yDQAd9KmGxIPEn/mzoCGPhMbgrVMqGXUse2bqNOafl/PEKpCSt8Yj/tvjD3ZvQXssST1XEpBg9HbiUVb4mOF+OZKN1r4k6Qr/3VBeEVXXieQIxKzOEK2q1Kr/RSdZT4wWEj3aLEbk6Kmhlxd3RUKmNx75Ik62GouOcnuLjN5JhH4nj33/rCN1EsJq/Nu4n/MwBJpaCcA0dh38rGoA5BacSGwTkEzsAiIYIQsiUdztsRmtEh+kxAJsO6eaR/gCzz7gD/7JsD4pRZQnTs4dnWGR8OjwlyUrys9RJ82IyhAkOQUfY1uaJoIH10wm8Dgw1p9m1eRkllGsoR+4e8vmGIfHSOlxE6yfP/EfRicfaKsXcts1+D+e/X2cZeRv7YQKY3ZUWlUg5xmVRwQUl1Kzzjpn+fP7fdEeI1qbT3xWtnJBUDbRrvQcE6eFpLKpbROAowaxxRpCTLtUozppqS0k0MBkCB3dp0nbs y8cohrwD cRluYUniA64ibtyxl5cYBcKckDlyIMUlbiyP/OHzhN9YSFDnOGk6rLkzQfELFmoLSq3WPb0d9zCLfNhO0QrQ9hy9WiIqB1/N38PCkxHkvpi0M9wzLcWm/4to8wv6QatozRPvD8+pFdqfc0ciMXgCu4vGs67uWqYlXagMYgQJRYNTcJdMojOlYmj4wSxyJzfBeTCJwhyV+bRBtI1c95e60IpfY9/M+wyZwfW5X1kZcat4eo1Bd6D280bn4a7RreQ5bRW72gNDtz/vqBfLY5xmj8zpXN1F62Xl3qUz9QGds6k9pjpgx719TXyXn+Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: The kernel-doc comment for 'struct damos_quota' describes how "effective quota" is calculated, but does not explain what it is. Actually there was an input[1] about it. Add the explanation on the comment. Also, fix a trivial typo on the comment block: s/empt/empty/ [1] https://github.com/damonitor/damo/issues/17#issuecomment-2497525043 Cc: Yunjeong Mun Cc: Honggyu Kim Suggested-by: Honggyu Kim Signed-off-by: SeongJae Park --- include/linux/damon.h | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/include/linux/damon.h b/include/linux/damon.h index 0834d7ffcb84..af525252b853 100644 --- a/include/linux/damon.h +++ b/include/linux/damon.h @@ -193,11 +193,16 @@ struct damos_quota_goal { * size quota is set, DAMON tries to apply the action only up to &sz bytes * within &reset_interval. * - * Internally, the time quota is transformed to a size quota using estimated - * throughput of the scheme's action. DAMON then compares it against &sz and - * uses smaller one as the effective quota. + * To convince the different types of quotas and goals, DAMON internally + * converts those into one single size quota called "effective quota". DAMON + * internally uses it as the only one real quota. The conversion is made as + * follows. * - * If @goals is not empt, DAMON calculates yet another size quota based on the + * The time quota is transformed to a size quota using estimated throughput of + * the scheme's action. DAMON then compares it against &sz and uses smaller + * one as the effective quota. + * + * If @goals is not empty, DAMON calculates yet another size quota based on the * goals using its internal feedback loop algorithm, for every @reset_interval. * Then, if the new size quota is smaller than the effective quota, it uses the * new size quota as the effective quota.