From patchwork Thu Jan 2 19:01:34 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 13924850 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 F0C54E77198 for ; Thu, 2 Jan 2025 19:01:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 710326B00F0; Thu, 2 Jan 2025 14:01:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6989B6B00F1; Thu, 2 Jan 2025 14:01:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 539646B00F2; Thu, 2 Jan 2025 14:01:49 -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 32A9D6B00F0 for ; Thu, 2 Jan 2025 14:01:49 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BBF491C5DE7 for ; Thu, 2 Jan 2025 19:01:48 +0000 (UTC) X-FDA: 82963429122.25.54D66AF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id B478F1C0014 for ; Thu, 2 Jan 2025 19:00:09 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KlaNlt1q; spf=pass (imf21.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=1735844483; 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=489WqIS4FGPYAKFmqMs4h4nKb5634AOpCg35Bl/JPNU=; b=7knnKeJSdH9T53pyBKzyyzvKUFLgFSnEVCDgrlNNOtpfVfpGF8VH3Z7AuJb7gdtVQH8SCT plb1nwgGoMt4GTjZaUuLy3/OIfBOvNrIeMzKewaCw+HOpkzxE9RHthR13bRnpIYtuBnIhK GLfrxH5OmjtgyXsvaYuHxeOAHeE2hc4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735844483; a=rsa-sha256; cv=none; b=dH+KMSAmFMxZS9A0EXwtRlW/y24utQdCiqylq9fnAG43DipvYDqEwcGyEOTSVO+8bOhJ0P HXKFQsRqWIBNgsHmfscN/P+maRuZofjgDWY76odk44dQJ/BXq/27zC0sIbTo05+x2fslo6 ZIVbDXEp4RtAyyL7PEW0nLLoS3znM5Y= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KlaNlt1q; spf=pass (imf21.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 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E172F5C61E1; Thu, 2 Jan 2025 19:01:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8238C4CEDC; Thu, 2 Jan 2025 19:01:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735844506; bh=4/XblnIScbbgUAgFK7pLL4JlbO5Pquped+azNdLMH04=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KlaNlt1q/Xrnqg9KnIF0LC2RgX+Ac0rYTpw11hklMkfAH+IxAsVsRuJCJ5h4yXHLe IfhtvCRALqjhqW1nvvDtp0Q/us47BbG5lAbxh8wH8u7+CdOGvO95WwZFNwSp3pdgV2 iKxRQ9X6q7XuGXlR/GV07BAQuIzTCQsqRrBwvUyqqdBbBJoYZ0OML/bIDrPJRTYwGS 5+9/kuIUoWmzE9be7bb1pLwsA7T5I5TSK2V6wUag6gE4vzlnBZFYe0UmHrTDD1p8ym oFlbv/P89jGbMgaBZkNDW4oWBg/aD4tuUQbzw/sz3/DpxjFtbUHrPiWaQkOZIvHm3Q hNAbNN++fIYbQ== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , Jonathan Corbet , damon@lists.linux.dev, kernel-team@meta.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 1/5] Docs/mm/damon/design: add monitoring parameters tuning guide Date: Thu, 2 Jan 2025 11:01:34 -0800 Message-Id: <20250102190138.47258-2-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250102190138.47258-1-sj@kernel.org> References: <20250102190138.47258-1-sj@kernel.org> MIME-Version: 1.0 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B478F1C0014 X-Stat-Signature: odxds9wk6z8yczpsbb18ooccbgswgx4x X-Rspam-User: X-HE-Tag: 1735844409-54499 X-HE-Meta: U2FsdGVkX1+iSCNV9mJrJ7t64NDgz9wPQtRJSyHqq90vyegthvZWOGRq8MC2Zsj43opec4ZkWcO31fQaWpN4hmd5SXbN1ZmWFqsvlx6i9/J7/jliKD2T7G/Pz5YvHlgnJ41s6z4bdNdEUt58L+NqHtv394AgooyTJMNtem/V09QQZwOj/2bPke+XB1Wqj5t5FTQ3QlPl2ALMp1s3noRElo0TEwnNGUSkxxRyFR4vyhyc5IH9eXIy7PhSxHPH0azjIDNmTDhUlqIg/leSjScR3nYaIP5NTqgdBpz9ZeScYyze+HIUAXAQ8riEAClPzRl0v8Ge26msLRndhh/iyLbMNV/2GmGTg1f0uLfLisUy+AgD7JqaC/h4BxbyJ4EDr2Xlllf7apAQxrjDjXKSer3YHoMqVuV/h8O3boIWG9zW79yEuFJQxVJPMXZDhFVkikAIHxUX73xW/qO8Jo+PmlFdZPSTAvyuGqf5hIQaJvEpMULTTLr1up2NYlbOZgXMPZNrDIRTlPQC39eBE6DnFnnoWfLtl7fX/12ut7VOXduUe3mOwzxuV8/H0RG70B9ajwLUyJZBhvC8NMipU0lCjk8PGnMYpGPcQ+z1IYVIPkCs71Xe8X7T4SNe5THDy0U77Iz2N+PSY0h9jv3/fb6ocdfa+LcwfeR2tsCFBGl6k8erMEz9ntOYYzfhMUZf4iTao6HMsFuZjVbUflcWlK0VUU7+0eEgXUsPxbyX3JsZGZKE5QIkqzCbHUbgN0DPP8msEJGCusc2V97O2Jm7vlOPKe2ldQPGC+ymvOfLWUTTn6P2D5bMk4ABWNwQ/haakqerGbpmty2kWfVR2CUfnrbam2i5Azc2AvSLVZ1BxIap4wWaaZZ8GB5+/qHVPCoq7qycbO+Vnts2qh3V8ATx2m0Atq/6vKCnqYEql1gqwL0NgIhuqAaeFl87EM92knrY6L1TxCqGQINrSITMZ4JF2JhSdAM sIffooOm ILaU4/XdDHrx+PFRanSTmJygwmmQI6d1QyqOIVs2ELHOWazxkq/MovkWUI5Vc2qUEx0IjvJ3lhu/96gIik5FFbbWeSZOMU0VeOf5dnPwu3uDirn/103a99dLErUnCh/aVn2NdjYtxBxdZV5TTlR6Hkb8NNJyEmINwOLYNjxu2az+4/XpNz2beRx3MrO6zGJSSBnDpp6rC2lPchqXxtjdRaFMkrdAN+XKEt/+DLdYWQjV0z9g= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000032, 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 require tunings 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]. 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 0265aaef2544..cc405e15d1b2 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