Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp397175pxm; Tue, 22 Feb 2022 13:15:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzKOVsk429NdemjsCHrBYromwbbRgkVrRyqMXILNj9EqY3O619oSFcjq8ksePxjQ+hoKOt2 X-Received: by 2002:a17:906:4d51:b0:6b8:78e0:565a with SMTP id b17-20020a1709064d5100b006b878e0565amr20456561ejv.587.1645564527636; Tue, 22 Feb 2022 13:15:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645564527; cv=none; d=google.com; s=arc-20160816; b=Aa41k5WosYVAisNWLAzMStgeL2MaQeNsBYwLj/wvpcnNFG7+lVwZydSmlIHusFkh7f IfR8Z1p0dOR537dhXPhmMkCjWRwwodoT/TDB5iPLd3OAEN4b1RTXE8mAPhZeJ6st5QYH sniYTmzpZVdjujHS9IzqHGhqT4YQpqSRFcTgT2gaPfdm5f0NIUpmilIbOcgzVnr5fcGA fgCcarItUWVGdVIVkX7t8Z3p4rmm3Vupq97tk5JJ9mUu/t4ENWKUJENgM+QnB0z0sjYn rwSRBC8uYdjIOvW4pM5e7uBx+kl9VfWkzsadB5DHnfVJuBFG6DqyuOiYnJUnYzD7pRR5 Ihbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=Kmhwb8f+ehamEyvn94BrQknlCX5KrzzDezq1wYZeoto=; b=RDmGcN+HzyyWOgDsiDPZ6RsiFjr2IY5FQi6wvjGVGIQIvuUww/jcs0iCeVAzf+Rn/o KbqL9CDP+Ozuekm8+Ra+/L8YT811+vlNgeAJzfmAJJKIq7l5AblgGtjPFmU+IFSmF9h+ UwoA+n8wId+I7WDT5iWgpCnM5ZXU5j+FE8FTt5a+g4tQUL0W3KbnoklWZCd6eRMMXGLM 0gFg6O4xq9TPNHhwPmhg2YWil1D62uofWIlqdS8SktoDSddYEZa1vo/9hEQLePcjl8+F kIYN3wk2OxB3UgJp5mYGvi+1Q9gWPn3Sx7+M5Q4Ok6PyyeXxl2eqzb8EmAW5mxrYn/jb Tmzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PpeSxOdg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l6si13451123ejo.931.2022.02.22.13.15.03; Tue, 22 Feb 2022 13:15:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PpeSxOdg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234458AbiBVRBf (ORCPT + 99 others); Tue, 22 Feb 2022 12:01:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231931AbiBVRBd (ORCPT ); Tue, 22 Feb 2022 12:01:33 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73B3B16E7DC; Tue, 22 Feb 2022 09:01:08 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 131F6611EF; Tue, 22 Feb 2022 17:01:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6580C340F3; Tue, 22 Feb 2022 17:01:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645549267; bh=39aGM7NlOoLZpgmNi6MB1SzF9U7sSJm7tFXEV8C9jgk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PpeSxOdgieBpb2HuJ2xeqElm5eBKelijp+KKuEHrsZVQf2uVih8WkryyO5VjnHslG xhG1Ipx94wrXOt3k5GiH+oaL0ai0Cna2OdVMpphGkNqNdWOaZeMxcfRgIiIkbXJywM oBjAO3qVoJMEqj8h5XU6/LVZjYyvQV0NI/p4Kqv+4eJaeb/ZYI/+0vPVAhICqC6DQg kOlyjy6cELoOpT54nyXNx29QZMFk6U3y9JYG9ZBv5Wrzbp6m6OY6WwDiLaUd7a1yOr iPtvNslEfFykVS0lHm0JT5Vp9sK52Xf+GwJDvQaADFJPn9AUKLgmevv+v/hU6QKMFC vtoGfRQLae27w== From: SeongJae Park To: akpm@linux-foundation.org Cc: corbet@lwn.net, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, SeongJae Park Subject: [PATCH 1/3] Docs/vm/damon: Call low level monitoring primitives the operations Date: Tue, 22 Feb 2022 17:00:58 +0000 Message-Id: <20220222170100.17068-2-sj@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220222170100.17068-1-sj@kernel.org> References: <20220222170100.17068-1-sj@kernel.org> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org DAMON code calls the low level monitoring primitives implementations the monitoring operations. The documentation would have no problem at still calling those primitives implementation because there is no real difference in the concepts, but making it more consistent with the code would make it better. This commit therefore convert sentences in the doc specifically pointing the implementations of the primitives to call it monitoring operations. Signed-off-by: SeongJae Park --- Documentation/vm/damon/design.rst | 24 ++++++++++++------------ Documentation/vm/damon/faq.rst | 2 +- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst index 210f0f50efd8..c406983aeb31 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -13,12 +13,13 @@ primitives that dependent on and optimized for the target address space. On the other hand, the accuracy and overhead tradeoff mechanism, which is the core of DAMON, is in the pure logic space. DAMON separates the two parts in different layers and defines its interface to allow various low level -primitives implementations configurable with the core logic. +primitives implementations configurable with the core logic. We call the low +level primitives implementations monitoring operations. Due to this separated design and the configurable interface, users can extend -DAMON for any address space by configuring the core logics with appropriate low -level primitive implementations. If appropriate one is not provided, users can -implement the primitives on their own. +DAMON for any address space by configuring the core logics with appropriate +monitoring operations. If appropriate one is not provided, users can implement +the operations on their own. For example, physical memory, virtual memory, swap space, those for specific processes, NUMA nodes, files, and backing memory devices would be supportable. @@ -26,25 +27,24 @@ Also, if some architectures or devices support special optimized access check primitives, those will be easily configurable. -Reference Implementations of Address Space Specific Primitives -============================================================== +Reference Implementations of Address Space Specific Monitoring Operations +========================================================================= -The low level primitives for the fundamental access monitoring are defined in -two parts: +The monitoring operations are defined in two parts: 1. Identification of the monitoring target address range for the address space. 2. Access check of specific address range in the target space. -DAMON currently provides the implementations of the primitives for the physical +DAMON currently provides the implementations of the operations for the physical and virtual address spaces. Below two subsections describe how those work. VMA-based Target Address Range Construction ------------------------------------------- -This is only for the virtual address space primitives implementation. That for -the physical address space simply asks users to manually set the monitoring -target address ranges. +This is only for the virtual address space monitoring operations +implementation. That for the physical address space simply asks users to +manually set the monitoring target address ranges. Only small parts in the super-huge virtual address space of the processes are mapped to the physical memory and accessed. Thus, tracking the unmapped diff --git a/Documentation/vm/damon/faq.rst b/Documentation/vm/damon/faq.rst index 11aea40eb328..dde7e2414ee6 100644 --- a/Documentation/vm/damon/faq.rst +++ b/Documentation/vm/damon/faq.rst @@ -31,7 +31,7 @@ Does DAMON support virtual memory only? ======================================= No. The core of the DAMON is address space independent. The address space -specific low level primitive parts including monitoring target regions +specific monitoring operations including monitoring target regions constructions and actual access checks can be implemented and configured on the DAMON core by the users. In this way, DAMON users can monitor any address space with any access check technique. -- 2.17.1