From mboxrd@z Thu Jan 1 00:00:00 1970 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68C0EC433EF for ; Tue, 12 Oct 2021 20:57:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F096610A4 for ; Tue, 12 Oct 2021 20:57:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1F096610A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A935194000D; Tue, 12 Oct 2021 16:57:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4410940007; Tue, 12 Oct 2021 16:57:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90B4594000D; Tue, 12 Oct 2021 16:57:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id 7D843940007 for ; Tue, 12 Oct 2021 16:57:47 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 69D3E3261A for ; Tue, 12 Oct 2021 20:57:46 +0000 (UTC) X-FDA: 78688996932.01.F378C0B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP id 0696BB00009D for ; Tue, 12 Oct 2021 20:57:45 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 967D8610D1; Tue, 12 Oct 2021 20:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634072265; bh=J5JGi5ZW1VXphRfAjWGvw8aX4WH1jIvTGdGvkWmPVBc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F9xpgG3uNG2pYVXqp14qBUxRRHcK1ah8h7ZUnNxScE2btRwRuFjN1Vx4yFIiEPaI7 8wJ4fliZUxWtrnNFJCi/nydfpwg/eN2qY/eMGDgkEaYdWkTeh26MS/xqyFrG842qem l6fAKVzKmZWlm+cSVTfgGTuWSjpCumrG6jZRkyhuQFRlhh4hFWQRBSz4EJ/cPNkZFC w31lfGvoEC0Fj168bkxVf8V2xYaYCLRcftaH/rc0d7pxvAANuAhDatT2DFWyR7JhRX zJPbnl3qZv9z1l5Jfbr/KHp22IgpQ/F30FefhMW+iawPMiA0AjTFYi/2u/cKeKPE3E P+gfs8vj7/hVw== From: SeongJae Park To: akpm@linux-foundation.org Cc: SeongJae Park , Jonathan.Cameron@Huawei.com, amit@kernel.org, benh@kernel.crashing.org, corbet@lwn.net, david@redhat.com, dwmw@amazon.com, elver@google.com, foersleo@amazon.de, gthelen@google.com, markubo@amazon.de, rientjes@google.com, shakeelb@google.com, shuah@kernel.org, linux-damon@amazon.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 7/7] Docs/DAMON: Document physical memory monitoring support Date: Tue, 12 Oct 2021 20:57:11 +0000 Message-Id: <20211012205711.29216-8-sj@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20211012205711.29216-1-sj@kernel.org> References: <20211012205711.29216-1-sj@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0696BB00009D X-Stat-Signature: fuk8ojmi5n6noo77cm71ssbohcd4yf3k Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=F9xpgG3u; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of sj@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=sj@kernel.org X-HE-Tag: 1634072265-209400 Content-Transfer-Encoding: quoted-printable 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: This commit updates the DAMON documents for the physical memory address space monitoring support. Signed-off-by: SeongJae Park --- Documentation/admin-guide/mm/damon/usage.rst | 25 +++++++++++++---- Documentation/vm/damon/design.rst | 29 ++++++++++++-------- Documentation/vm/damon/faq.rst | 5 ++-- 3 files changed, 40 insertions(+), 19 deletions(-) diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation= /admin-guide/mm/damon/usage.rst index f7d5cfbb50c2..ed96bbf0daff 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -10,15 +10,16 @@ DAMON provides below three interfaces for different u= sers. This is for privileged people such as system administrators who want a just-working human-friendly interface. Using this, users can use the = DAMON=E2=80=99s major features in a human-friendly way. It may not be highly tuned fo= r - special cases, though. It supports only virtual address spaces monito= ring. + special cases, though. It supports both virtual and physical address = spaces + monitoring. - *debugfs interface.* This is for privileged user space programmers who want more optimized = use of DAMON. Using this, users can use DAMON=E2=80=99s major features by re= ading from and writing to special debugfs files. Therefore, you can write a= nd use your personalized DAMON debugfs wrapper programs that reads/writes the debugfs files instead of you. The DAMON user space tool is also a ref= erence - implementation of such programs. It supports only virtual address spa= ces - monitoring. + implementation of such programs. It supports both virtual and physica= l + address spaces monitoring. - *Kernel Space Programming Interface.* This is for kernel space programmers. Using this, users can utilize e= very feature of DAMON most flexibly and efficiently by writing kernel space @@ -72,20 +73,34 @@ check it again:: # cat target_ids 42 4242 =20 +Users can also monitor the physical memory address space of the system b= y +writing a special keyword, "``paddr\n``" to the file. Because physical = address +space monitoring doesn't support multiple targets, reading the file will= show a +fake value, ``42``, as below:: + + # cd /damon + # echo paddr > target_ids + # cat target_ids + 42 + Note that setting the target ids doesn't start the monitoring. =20 =20 Initial Monitoring Target Regions --------------------------------- =20 -In case of the debugfs based monitoring, DAMON automatically sets and up= dates -the monitoring target regions so that entire memory mappings of target +In case of the virtual address space monitoring, DAMON automatically set= s and +updates the monitoring target regions so that entire memory mappings of = target processes can be covered. However, users can want to limit the monitori= ng region to specific address ranges, such as the heap, the stack, or speci= fic file-mapped area. Or, some users can know the initial access pattern of= their workloads and therefore want to set optimal initial regions for the 'ada= ptive regions adjustment'. =20 +In contrast, DAMON do not automatically sets and updates the monitoring = target +regions in case of physical memory monitoring. Therefore, users should = set the +monitoring target regions by themselves. + In such cases, users can explicitly set the initial monitoring target re= gions as they want, by writing proper values to the ``init_regions`` file. Ea= ch line of the input should represent one region in below form.:: diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/d= esign.rst index b05159c295f4..210f0f50efd8 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -35,13 +35,17 @@ 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. =20 -DAMON currently provides the implementation of the primitives for only t= he -virtual address spaces. Below two subsections describe how it works. +DAMON currently provides the implementations of the primitives for the p= hysical +and virtual address spaces. Below two subsections describe how those wor= k. =20 =20 VMA-based Target Address Range Construction ------------------------------------------- =20 +This is only for the virtual address space primitives implementation. T= hat for +the physical address space simply asks users to manually set the monitor= ing +target address ranges. + Only small parts in the super-huge virtual address space of the processe= s are mapped to the physical memory and accessed. Thus, tracking the unmapped address regions is just wasteful. However, because DAMON can deal with = some @@ -71,15 +75,18 @@ to make a reasonable trade-off. Below shows this in = detail:: PTE Accessed-bit Based Access Check ----------------------------------- =20 -The implementation for the virtual address space uses PTE Accessed-bit f= or -basic access checks. It finds the relevant PTE Accessed bit from the ad= dress -by walking the page table for the target task of the address. In this w= ay, the -implementation finds and clears the bit for next sampling target address= and -checks whether the bit set again after one sampling period. This could = disturb -other kernel subsystems using the Accessed bits, namely Idle page tracki= ng and -the reclaim logic. To avoid such disturbances, DAMON makes it mutually -exclusive with Idle page tracking and uses ``PG_idle`` and ``PG_young`` = page -flags to solve the conflict with the reclaim logic, as Idle page trackin= g does. +Both of the implementations for physical and virtual address spaces use = PTE +Accessed-bit for basic access checks. Only one difference is the way of +finding the relevant PTE Accessed bit(s) from the address. While the +implementation for the virtual address walks the page table for the targ= et task +of the address, the implementation for the physical address walks every = page +table having a mapping to the address. In this way, the implementations= find +and clear the bit(s) for next sampling target address and checks whether= the +bit(s) set again after one sampling period. This could disturb other ke= rnel +subsystems using the Accessed bits, namely Idle page tracking and the re= claim +logic. To avoid such disturbances, DAMON makes it mutually exclusive wi= th Idle +page tracking and uses ``PG_idle`` and ``PG_young`` page flags to solve = the +conflict with the reclaim logic, as Idle page tracking does. =20 =20 Address Space Independent Core Mechanisms diff --git a/Documentation/vm/damon/faq.rst b/Documentation/vm/damon/faq.= rst index cb3d8b585a8b..11aea40eb328 100644 --- a/Documentation/vm/damon/faq.rst +++ b/Documentation/vm/damon/faq.rst @@ -36,10 +36,9 @@ constructions and actual access checks can be implemen= ted and configured on the DAMON core by the users. In this way, DAMON users can monitor any addre= ss space with any access check technique. =20 -Nonetheless, DAMON provides vma tracking and PTE Accessed bit check base= d +Nonetheless, DAMON provides vma/rmap tracking and PTE Accessed bit check= based implementations of the address space dependent functions for the virtual= memory -by default, for a reference and convenient use. In near future, we will -provide those for physical memory address space. +and the physical memory by default, for a reference and convenient use. =20 =20 Can I simply monitor page granularity? --=20 2.17.1