From patchwork Mon Feb 24 12:30:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: SeongJae Park X-Patchwork-Id: 11400361 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0783114E3 for ; Mon, 24 Feb 2020 12:31:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F54F20732 for ; Mon, 24 Feb 2020 12:31:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="t1X4SY7L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F54F20732 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A57CD6B0005; Mon, 24 Feb 2020 07:31:37 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id A09C56B0006; Mon, 24 Feb 2020 07:31:37 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F68A6B0007; Mon, 24 Feb 2020 07:31:37 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 706206B0005 for ; Mon, 24 Feb 2020 07:31:37 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3EA023489 for ; Mon, 24 Feb 2020 12:31:37 +0000 (UTC) X-FDA: 76524956634.28.magic01_4822cb330954a X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,prvs=316760060=sjpark@amazon.com,,RULES_HIT:30003:30005:30006:30012:30016:30029:30034:30041:30045:30051:30054:30055:30056:30064:30070:30074:30075:30090:30091,0,RBL:207.171.184.29:@amazon.com:.lbl8.mailshell.net-66.10.201.10 62.18.0.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:none,Custom_rules:0:2:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: magic01_4822cb330954a X-Filterd-Recvd-Size: 32408 Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Feb 2020 12:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1582547496; x=1614083496; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=6GHj7rDQqtqbgtSw4dTFHKM5z0BbvIffuFWAI3ahAB0=; b=t1X4SY7LRWuVuWl+2X4EtJl0t8d9cbPpCL+9GqSC94qtlJei2Gu0NaXK k/ZKNtbjDUkEdWgDyT4iwWRDlY38O2YglrGJe3Ux0k+bQZllMcaH590Yf u9ZXVbefvDAyl9z2vZ03L0BYNpNIR31INXxw5fpHLe9m2c7fUGczsPbaj I=; IronPort-SDR: avNuTuvlGJhvohzdCysezTdRfuzje41dKr0HXlOWrlvjmI099VaDajpharcFY3DUp3JN5jgMRZ vv2KBXummN+w== X-IronPort-AV: E=Sophos;i="5.70,480,1574121600"; d="scan'208";a="27075812" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 24 Feb 2020 12:31:32 +0000 Received: from EX13MTAUEA002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com (Postfix) with ESMTPS id 4B62CA06D4; Mon, 24 Feb 2020 12:31:30 +0000 (UTC) Received: from EX13D31EUA001.ant.amazon.com (10.43.165.15) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 24 Feb 2020 12:31:29 +0000 Received: from u886c93fd17d25d.ant.amazon.com (10.43.162.53) by EX13D31EUA001.ant.amazon.com (10.43.165.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 24 Feb 2020 12:31:17 +0000 From: SeongJae Park To: CC: SeongJae Park , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v6 00/14] Introduce Data Access MONitor (DAMON) Date: Mon, 24 Feb 2020 13:30:33 +0100 Message-ID: <20200224123047.32506-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 X-Originating-IP: [10.43.162.53] X-ClientProxiedBy: EX13D19UWC003.ant.amazon.com (10.43.162.184) To EX13D31EUA001.ant.amazon.com (10.43.165.15) 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: From: SeongJae Park Introduction ============ Memory management decisions can be improved if finer data access information is available. However, because such finer information usually comes with higher overhead, most systems including Linux forgives the potential improvement and rely on only coarse information or some light-weight heuristics. The pseudo-LRU and the aggressive THP promotions are such examples. A number of experimental data access pattern awared memory management optimizations (refer to 'Appendix A' for more details) say the sacrifices are huge. However, none of those has successfully adopted to Linux kernel mainly due to the absence of a scalable and efficient data access monitoring mechanism. Refer to 'Appendix B' to see the limitations of existing memory monitoring mechanisms. DAMON is a data access monitoring subsystem for the problem. It is 1) accurate enough to be used for the DRAM level memory management (a straightforward DAMON-based optimization achieved up to 2.55x speedup), 2) light-weight enough to be applied online (compared to a straightforward access monitoring scheme, DAMON is up to 94.242.42x lighter) and 3) keeps predefined upper-bound overhead regardless of the size of target workloads (thus scalable). Refer to 'Appendix C' if you interested in how it is possible. DAMON has mainly designed for the kernel's memory management mechanisms. However, because it is implemented as a standalone kernel module and provides several interfaces, it can be used by a wide range of users including kernel space programs, user space programs, programmers, and administrators. DAMON is now supporting the monitoring only, but it will also provide simple and convenient data access pattern awared memory managements by itself. Refer to 'Appendix D' for more detailed expected usages of DAMON. Visualized Outputs of DAMON =========================== For intuitively understanding of DAMON, I made web pages[1-8] showing the visualized dynamic data access pattern of various realistic workloads, which I picked up from PARSEC3 and SPLASH-2X bechmark suites. The figures are generated using the user space tool in 10th patch of this patchset. There are pages showing the heatmap format dynamic access pattern of each workload for heap area[1], mmap()-ed area[2], and stack[3] area. I splitted the entire address space to the three area because there are huge unmapped regions between the areas. You can also show how the dynamic working set size of each workload is distributed[4], and how it is chronologically changing[5]. The most important characteristic of DAMON is its promise of the upperbound of the monitoring overhead. To show whether DAMON keeps the promise well, I visualized the number of monitoring operations required for each 5 milliseconds, which is configured to not exceed 1000. You can show the distribution of the numbers[6] and how it changes chronologically[7]. [1] https://damonitor.github.io/reports/latest/by_image/heatmap.0.png.html [2] https://damonitor.github.io/reports/latest/by_image/heatmap.1.png.html [3] https://damonitor.github.io/reports/latest/by_image/heatmap.2.png.html [4] https://damonitor.github.io/reports/latest/by_image/wss_sz.png.html [5] https://damonitor.github.io/reports/latest/by_image/wss_time.png.html [6] https://damonitor.github.io/reports/latest/by_image/nr_regions_sz.png.html [7] https://damonitor.github.io/reports/latest/by_image/nr_regions_time.png.html Data Access Monitoring-based Operation Schemes ============================================== As 'Appendix D' describes, DAMON can be used for data access monitoring-based operation schemes (DAMOS). RFC patchsets for DAMOS are already available (https://lore.kernel.org/linux-mm/20200218085309.18346-1-sjpark@amazon.com/). By applying a very simple scheme for THP promotion/demotion with a latest version of the patchset (not posted yet), DAMON achieved 18x lower memory space overhead compared to THP while preserving about 50% of the THP performance benefit with SPLASH-2X benchmark suite. The detailed setup and number will be posted soon with the next RFC patchset for DAMOS. The posting is currently scheduled for tomorrow. Frequently Asked Questions ========================== Q: Why DAMON is not integrated with perf? A: From the perspective of perf like profilers, DAMON can be thought of as a data source in kernel, like the tracepoints, the pressure stall information (psi), or the idle page tracking. Thus, it is easy to integrate DAMON with the profilers. However, this patchset doesn't provide a fancy perf integration because current step of DAMON development is focused on its core logic only. That said, DAMON already provides two interfaces for user space programs, which based on debugfs and tracepoint, respectively. Using the tracepoint interface, you can use DAMON with perf. This patchset also provides a debugfs interface based user space tool for DAMON. It can be used to record, visualize, and analyze data access patterns of target processes in a convenient way. Q: Why a new module, instead of extending perf or other tools? A: First, DAMON aims to be used by other programs including the kernel. Therefore, having dependency to specific tools like perf is not desirable. Second, because it need to be lightweight as much as possible so that it can be used online, any unnecessary overhead such as kernel - user space context switching cost should be avoided. These are the two most biggest reasons why DAMON is implemented in the kernel space. The idle page tracking subsystem would be the kernel module that most seems similar to DAMON. However, its own interface is not compatible with DAMON. Also, the internal implementation of it has no common part to be reused by DAMON. Q: Can 'perf mem' provide the data required for DAMON? A: On the systems supporting 'perf mem', yes. DAMON is using the PTE Accessed bits in low level. Other H/W or S/W features that can be used for the purpose could be used. However, as explained with above question, DAMON need to be implemented in the kernel space. Evaluations =========== A prototype of DAMON has evaluated on an Intel Xeon E7-8837 machine using 20 benchmarks that picked from SPEC CPU 2006, NAS, Tensorflow Benchmark, SPLASH-2X, and PARSEC 3 benchmark suite. Nonethless, this section provides only summary of the results. For more detail, please refer to the slides used for the introduction of DAMON at the Linux Plumbers Conference 2019[1] or the MIDDLEWARE'19 industrial track paper[2]. Quality ------- We first traced and visualized the data access pattern of each workload. We were able to confirm that the visualized results are reasonably accurate by manually comparing those with the source code of the workloads. To see the usefulness of the monitoring, we optimized 9 memory intensive workloads among them for memory pressure situations using the DAMON outputs. In detail, we identified frequently accessed memory regions in each workload based on the DAMON results and protected them with ``mlock()`` system calls. The optimized versions consistently show speedup (2.55x in best case, 1.65x in average) under memory pressure. Overhead -------- We also measured the overhead of DAMON. It was not only under the upperbound we set, but was much lower (0.6 percent of the bound in best case, 13.288 percent of the bound in average). This reduction of the overhead is mainly resulted from its core mechanism called adaptive regions adjustment. Refer to 'Appendix D' for more detail about the mechanism. We also compared the overhead of DAMON with that of a straightforward periodic access check-based monitoring. DAMON's overhead was smaller than it by 94,242.42x in best case, 3,159.61x in average. The latest version of DAMON running with its default configuration consumes only up to 1% of CPU time when applied to realistic workloads in PARSEC3 and SPLASH-2X and makes no visible slowdown to the target processes. References ========== Prototypes of DAMON have introduced by an LPC kernel summit track talk[1] and two academic papers[2,3]. Please refer to those for more detailed information, especially the evaluations. The latest version of the patchsets has also introduced by an LWN artice[4]. [1] SeongJae Park, Tracing Data Access Pattern with Bounded Overhead and Best-effort Accuracy. In The Linux Kernel Summit, September 2019. https://linuxplumbersconf.org/event/4/contributions/548/ [2] SeongJae Park, Yunjae Lee, Heon Y. Yeom, Profiling Dynamic Data Access Patterns with Controlled Overhead and Quality. In 20th ACM/IFIP International Middleware Conference Industry, December 2019. https://dl.acm.org/doi/10.1145/3366626.3368125 [3] SeongJae Park, Yunjae Lee, Yunhee Kim, Heon Y. Yeom, Profiling Dynamic Data Access Patterns with Bounded Overhead and Accuracy. In IEEE International Workshop on Foundations and Applications of Self- Systems (FAS 2019), June 2019. [4] Jonathan Corbet, Memory-management optimization with DAMON. In Linux Weekly News (LWN), Feb 2020. https://lwn.net/Articles/812707/ Sequence Of Patches =================== The patches are organized in the following sequence. The first patch introduces DAMON module, it's data structures, and data structure related common functions. Following three patches (2nd to 4th) implement the core logics of DAMON, namely regions based sampling, adaptive regions adjustment, and dynamic memory mapping chage adoption, one by one. Following five patches are for low level users of DAMON. The 5th patch implements callbacks for each of monitoring steps so that users can do whatever they want with the access patterns. The 6th one implements recording of access patterns in DAMON for better convenience and efficiency. Each of next three patches (7th to 9th) respectively adds a programmable interface for other kernel code, a debugfs interface for privileged people and/or programs in user space, and a tracepoint for other tracepoints supporting tracers such as perf. Two patches for high level users of DAMON follows. To provide a minimal reference to the debugfs interface and for high level use/tests of the DAMON, the next patch (10th) implements an user space tool. The 11th patch adds a document for administrators of DAMON. Next two patches are for tests. The 12th and 13th patches provide unit tests (based on kunit) and user space tests (based on kselftest) respectively. Finally, the last patch (14th) updates the MAINTAINERS file. The patches are based on the v5.5. You can also clone the complete git tree: $ git clone git://github.com/sjp38/linux -b damon/patches/v6 The web is also available: https://github.com/sjp38/linux/releases/tag/damon/patches/v6 Patch History ============= Changes from v5 (https://lore.kernel.org/linux-mm/20200217103110.30817-1-sjpark@amazon.com/) - Fix minor bugs (sampling, record attributes, debugfs and user space tool) - selftests: Add debugfs interface tests for the bugs - Modify the user space tool to use its self default values for parameters - Fix pmg huge page access check Changes from v4 (https://lore.kernel.org/linux-mm/20200210144812.26845-1-sjpark@amazon.com/) - Add 'Reviewed-by' for the kunit tests patch (Brendan Higgins) - Make the unit test to depedns on 'DAMON=y' (Randy Dunlap and kbuild bot) Reported-by: kbuild test robot - Fix m68k module build issue Reported-by: kbuild test robot - Add selftests - Seperate patches for low level users from core logics for better reading - Clean up debugfs interface - Trivial nitpicks Changes from v3 (https://lore.kernel.org/linux-mm/20200204062312.19913-1-sj38.park@gmail.com/) - Fix i386 build issue Reported-by: kbuild test robot - Increase the default size of the monitoring result buffer to 1 MiB - Fix misc bugs in debugfs interface Changes from v2 (https://lore.kernel.org/linux-mm/20200128085742.14566-1-sjpark@amazon.com/) - Move MAINTAINERS changes to last commit (Brendan Higgins) - Add descriptions for kunittest: why not only entire mappings and what the 4 input sets are trying to test (Brendan Higgins) - Remove 'kdamond_need_stop()' test (Brendan Higgins) - Discuss about the 'perf mem' and DAMON (Peter Zijlstra) - Make CV clearly say what it actually does (Peter Zijlstra) - Answer why new module (Qian Cai) - Diable DAMON by default (Randy Dunlap) - Change the interface: Seperate recording attributes (attrs, record, rules) and allow multiple kdamond instances - Implement kernel API interface Changes from v1 (https://lore.kernel.org/linux-mm/20200120162757.32375-1-sjpark@amazon.com/) - Rebase on v5.5 - Add a tracepoint for integration with other tracers (Kirill A. Shutemov) - document: Add more description for the user space tool (Brendan Higgins) - unittest: Improve readability (Brendan Higgins) - unittest: Use consistent name and helpers function (Brendan Higgins) - Update PG_Young to avoid reclaim logic interference (Yunjae Lee) Changes from RFC (https://lore.kernel.org/linux-mm/20200110131522.29964-1-sjpark@amazon.com/) - Specify an ambiguous plan of access pattern based mm optimizations - Support loadable module build - Cleanup code SeongJae Park (14): mm: Introduce Data Access MONitor (DAMON) mm/damon: Implement region based sampling mm/damon: Adaptively adjust regions mm/damon: Apply dynamic memory mapping changes mm/damon: Implement callbacks mm/damon: Implement access pattern recording mm/damon: Implement kernel space API mm/damon: Add debugfs interface mm/damon: Add a tracepoint for result writing tools: Add a minimal user-space tool for DAMON Documentation/admin-guide/mm: Add a document for DAMON mm/damon: Add kunit tests mm/damon: Add user selftests MAINTAINERS: Update for DAMON .../admin-guide/mm/data_access_monitor.rst | 414 +++++ Documentation/admin-guide/mm/index.rst | 1 + MAINTAINERS | 12 + include/linux/damon.h | 71 + include/trace/events/damon.h | 32 + mm/Kconfig | 23 + mm/Makefile | 1 + mm/damon-test.h | 604 +++++++ mm/damon.c | 1427 +++++++++++++++++ mm/page_ext.c | 1 + tools/damon/.gitignore | 1 + tools/damon/_dist.py | 36 + tools/damon/bin2txt.py | 64 + tools/damon/damo | 37 + tools/damon/heats.py | 358 +++++ tools/damon/nr_regions.py | 89 + tools/damon/record.py | 212 +++ tools/damon/report.py | 45 + tools/damon/wss.py | 95 ++ tools/testing/selftests/damon/Makefile | 7 + .../selftests/damon/_chk_dependency.sh | 28 + tools/testing/selftests/damon/_chk_record.py | 89 + .../testing/selftests/damon/debugfs_attrs.sh | 139 ++ .../testing/selftests/damon/debugfs_record.sh | 50 + 24 files changed, 3836 insertions(+) create mode 100644 Documentation/admin-guide/mm/data_access_monitor.rst create mode 100644 include/linux/damon.h create mode 100644 include/trace/events/damon.h create mode 100644 mm/damon-test.h create mode 100644 mm/damon.c create mode 100644 tools/damon/.gitignore create mode 100644 tools/damon/_dist.py create mode 100644 tools/damon/bin2txt.py create mode 100755 tools/damon/damo create mode 100644 tools/damon/heats.py create mode 100644 tools/damon/nr_regions.py create mode 100644 tools/damon/record.py create mode 100644 tools/damon/report.py create mode 100644 tools/damon/wss.py create mode 100644 tools/testing/selftests/damon/Makefile create mode 100644 tools/testing/selftests/damon/_chk_dependency.sh create mode 100644 tools/testing/selftests/damon/_chk_record.py create mode 100755 tools/testing/selftests/damon/debugfs_attrs.sh create mode 100755 tools/testing/selftests/damon/debugfs_record.sh