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