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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ACF2E77188 for ; Thu, 2 Jan 2025 18:00:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FF756B00E5; Thu, 2 Jan 2025 13:00:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AFAF6B00E6; Thu, 2 Jan 2025 13:00:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 776DC6B00E7; Thu, 2 Jan 2025 13:00:27 -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 59DDB6B00E5 for ; Thu, 2 Jan 2025 13:00:27 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 08025AE723 for ; Thu, 2 Jan 2025 18:00:27 +0000 (UTC) X-FDA: 82963273470.09.C3ADEAC Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf15.hostedemail.com (Postfix) with ESMTP id 67ED5A001A for ; Thu, 2 Jan 2025 17:58:52 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fCPO9uSE; spf=pass (imf15.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=1735840765; 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=S1lRqx6napbPSxnLl4eUbDRKqWoTLDuiABO9jepTmTE=; b=laMjHgxuelZm/SO/dncV0k3Ciu9zlgv6o6IggELI9X7ViRh0udlD/akOcZBWd4Yb4x8hSI CqYTIfAKtOCDqhoj+G+9zooutFt6Yl9FL+3yzzXx0+ZzjVk8Z7++SDyIVQaqRhyMrWJKWF +oOr4Fi1IIq4nUleT8hN4/7Gv+ZgKJU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735840765; a=rsa-sha256; cv=none; b=lOZEoCM+/6VKBUPvDmv1wMQUZMImZ1k0lryAWeDkjUi5OEpA3I/y60BWC1PtGkOk/Z0s3/ ZizusU7lyhvlXEnUldO1TLXekerF81yeL43lypcpx2TWTdjPNxZ/JA4xReVmmetXL9WeUs Zcu3TC1j3QW7gS/ndg9B3Kn6bpz80n4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fCPO9uSE; spf=pass (imf15.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 31283A4133D; Thu, 2 Jan 2025 17:58:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E18B6C4CED0; Thu, 2 Jan 2025 18:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735840824; bh=Qj6Vi+cCoEpj+xxJDyjM/jsYt8XRH2kLoMBA7rnKpqU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fCPO9uSE6fuG82QXUdh0UjXBNn0FliqcCNby6+vXW2HBXxFUAMbKR3+d9b9wGyBf3 ciOHnsmBk9RJ9CV4YL17zeeOoNDdnQEspQvvdyWEJ254ZsPxLe0JM0lMYM0VQwnAxy Mib7PvF1v+Q1iO2OOG2JwaanqvogfeLgM8u5jdipdFJQU5UjhFgcnrPGGlhXmWebFO 7RZ5PfpqCV5soCfZELUrXdJAI6LC1QFRQk7ZI782vQx/lurlMT2yVTzOjYyRtWInr0 mZP3SIDdWfbevlTzX9/0jyJhwROsY1VIXGx/hCg6X+OmXEmv2H34prQ28GGxNQEsLI u4t8raqNqEhQg== From: SeongJae Park To: Gregory Price Cc: SeongJae Park , Matthew Wilcox , lsf-pc@lists.linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Raghavendra K T , Yuanchu Xie , Jonathan Cameron , Kaiyang Zhao , Jiaming Yan , Honggyu Kim Subject: Re: [LSF/MM/BPF TOPIC] DAMON Requirements for Access-aware MM of Future Date: Thu, 2 Jan 2025 10:00:19 -0800 Message-Id: <20250102180019.45333-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 67ED5A001A X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 8kob7mcju1boixri7hif6k7byrsygcmq X-HE-Tag: 1735840732-550454 X-HE-Meta: U2FsdGVkX19DXU2dSAXAH4fS4ep693kZ7oMbK2XcRmJ/QC383O+wf7zfGIlR++bx6qcs7vAJQxlzeYIOrx6wB2yez6sECy4MWXRuQ83eyR38FXe07Zuz1yUwHb422a4UNgKje12tmXF77QwJtAy0wwaNAubmHuINM/mP19+WL6xXKiXUc6LGSGQywPoV9xMRdEVxFGIuB5nqYGkLzAKcDHSA6KOKWHMFvkG3ulL5NdyzMIffKZO3kTeOa4VMcriuLRsb/ZJrihovDZMLyBAWJRqGdmOUqanmM8lcACc/dVxL5m/JI6kEHRsF+gb80nl/l4HHCj16IT5HHzibNE+sHDHMww+FGUkd6kKgMA55W9rksG0TIqrJ5YRe8zu+/uw1i9S7tNB0UEs71yMNtOoOJrgJutN6dNacCXQFVstIKlM5DPQ7EO25wrpWMhQNVpu8TkTNVJ9QngwUe4LOa0vyAH4iXjdkh4ArK3LRPaGkjzAleVJzVynJpjkYNNLZHIrE8sjjWjgjY494BQGrMqiuO8L9cc9nDQPngpRUYjUju3zAPcgpVONokzYAfuqWXzOodw9Ad4M534wx8TKsrcBP7MUULBLS2f0tVuHcQWkffmXCxzrOmGqUEpjk+88e0Wc19Op6HAZI+oNTICDVZtCqmyAfWdkgXdKFbEMZX4FRMzqW9g2yvsgyEfDgDxapdU4iRT7TRjyAhYLTNPEhKf/SaQjijJjKw1j+V7bQf3s+9l9J3gqA1ipS3tSjXZfuZHjfvxOxp8uETlt/DMEMPtJR+ZKQett1vSnCKH09V+MKIETz7M8+yFvVPvQXFDqmGpsO4Otb69GANBRMhBP+HLj4DcfAfJcfph8iH6SPO12tsW4GPe1rTB4TWj1ULd1pSDWRUgQGKp1W/yDctxXBmmhVUCUd8bA9HMYSrGbMqI00W3jrYJMN/2OkhzI9Ah+TqUIrasUe9bx2sFOgbr7VboS xvvQPz5x qSHkmPi7/Sh+TsqJWWpOhLNMHHNsKzcGz3ha/QB1wgiZz4gJ9dK/rgs9BxRfsEsNc+ghFSCQt0YXTmjFtRCuG2As1srjJa5FxQP2MVTgNzwBLk4P//ZaIdUiHj+BzESkM33xy4DBgRTwPgYwV2NtW450KnZ99YkCi/WDOE9l1a+W4iQ8JNMQyeTLTl7+O5oVkD3QFBDz9eE4gz5+0OOMyrvguOpQ7hyUI63MmR2Iq4wgrAmba4EQ0sE9yr26S3I3GwVfnalWKlp2YoLezQP1KvGytw63JSg7AjbeJp6Gm91rso0RryY6zZ3M6Ty2MiwX9W2fJTkJ0IR5YF1HTFv5FxA9/gg== 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: List-Subscribe: List-Unsubscribe: On Thu, 2 Jan 2025 10:22:14 -0500 Gregory Price wrote: > On Thu, Jan 02, 2025 at 04:09:38AM +0000, Matthew Wilcox wrote: > > On Wed, Jan 01, 2025 at 02:20:39PM -0800, SeongJae Park wrote: > > > Hi all, > > > > > > > > > I find a few interesting and promising projects that aim to do efficient access > > > pattern-aware memory management of near future, including below (alphabetically > > > sorted). > > > > > > - CXL hotness monitoring unit > > > (https://lore.kernel.org/20241121101845.1815660-1-Jonathan.Cameron@huawei.com) > > > - Memory tiering fainess by per-cgroup control of promotion and demotion > > > (https://lore.kernel.org/20241108190152.3587484-1-kaiyang2@cs.cmu.edu) > > > - Promotion of unmapped page cache folios > > > (https://lore.kernel.org/20241210213744.2968-1-gourry@gourry.net) > > > > I'm not sure how DAMON can help with this one. As I understand DAMON, > > it monitors accesses to user addresses. This patchset is trying to solve > > the problem for file pages which aren't mapped to userspace at all. > > ie only accessed through read() and write(). > > DAMON can monitor physical addresses to, though the mechanism is > different. Thank you for answering this, Gregory. As Gregory explained, users can use physical address monitoring mode of DAMON for this. For unmapped pages, DAMON sets and reads PG_idle to check if it is accessed or not. Since PG_idle is respected by read() and write() use case to my understanding, DAMON should be able to check accesses to unmapped pages. > I haven't assessed this as a solution, yet. To quickly see this, I ran below simple test. First, I start DAMON in physical address space monitoring mode, wait for one minutes to let it monitor the accesses of the system, and show the access pattern on the system in access temperature histogram format. $ sudo ./damo start $ sleep 60 $ sudo ./damo report access --style temperature-sz-hist [-7,480,000,000, -7,479,999,999) 59.868 GiB | | total size: 59.868 GiB The access temperature histogram format shows size of memory of given access temperature range. Access temperature is a metric that represents the access hotness. If any access to the region is continuously found, the value increases. If no access to the region is found, the temperature becomes zero. If it continues showing no access, the temperature further decreases (goes to minus). Refer to the document[1] for more details. So from the above output, we can show all memory of the system is not accessed at all for the last minute. Now I start a program that continuously overwrites 10 GiB file in background. Attaching the source code (Attachment 0, dd_like.c) at the bottom of this mail. After a few seconds, I show the temperature histogram again. $ sudo ./damo report access --style temperature-sz-hist [-12,590,000,000, -11,699,000,000) 42.038 GiB |********************| [-11,699,000,000, -10,808,000,000) 0 B | | [-10,808,000,000, -9,917,000,000) 0 B | | [-9,917,000,000, -9,026,000,000) 0 B | | [-9,026,000,000, -8,135,000,000) 5.986 GiB |*** | [-8,135,000,000, -7,244,000,000) 0 B | | [-7,244,000,000, -6,353,000,000) 0 B | | [-6,353,000,000, -5,462,000,000) 0 B | | [-5,462,000,000, -4,571,000,000) 0 B | | [-4,571,000,000, -3,680,000,000) 5.951 GiB |*** | [-3,680,000,000, -2,789,000,000) 5.893 GiB |*** | total size: 59.868 GiB We can show DAMON found about 10 GiB relatively hot regions. This is a very simple test that not well tuned. Maybe because of that, there are details to investigate, including why the 10 GiB regions are having different and negative access temperature. I'll skip those for now, since the point of this test is that DAMON at least somehow react to accesses for unmapped pages. [1] https://github.com/damonitor/damo/blob/next/USAGE.md#access-temperature Thanks, SJ > > ~Gregory ==== Attachment 0 (dd_like.c) ==== #include #include #include #include #include #include int main(int argc, char *argv[]) { int block_size, count; char *dest_path; if (argc != 4) { printf("Usage: ./dd_simulator \n"); return 1; } block_size = atoi(argv[1]); count = atoi(argv[2]); dest_path = argv[3]; // Validate input parameters if (block_size <= 0 || count <= 0) { fprintf(stderr, "Invalid block size or count\n"); return 1; } // Write block size of zeroes 'count' times char *zeroes = calloc(block_size, sizeof(char)); if (!zeroes) { fprintf(stderr, "Memory allocation failed\n"); return 1; } while (1) { // Open destination file in write mode FILE *dest_file = fopen(dest_path, "w"); if (!dest_file) { fprintf(stderr, "Failed to open %s for writing: %s\n", dest_path, strerror(errno)); return 1; } // Write block size of zeroes 'count' times for (int i = 0; i < count; i++) fwrite(zeroes, block_size, 1, dest_file); fclose(dest_file); printf("one pass"); } free(zeroes); return 0; }