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 DEE05C0218A for ; Thu, 30 Jan 2025 03:47:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F26F2800B6; Wed, 29 Jan 2025 22:47:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 27B5A2800B5; Wed, 29 Jan 2025 22:47:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F4762800B6; Wed, 29 Jan 2025 22:47:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E31452800B5 for ; Wed, 29 Jan 2025 22:47:58 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 992DCA07C4 for ; Thu, 30 Jan 2025 03:47:58 +0000 (UTC) X-FDA: 83062734636.25.E6A9984 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id DF36DA0004 for ; Thu, 30 Jan 2025 03:47:56 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=odFBvwdO; spf=pass (imf15.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=1738208877; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cuUN3Qhvb6OJKUCrGzr42LEIaSZbTP0QLKbl0AlB9RQ=; b=elRTIsBFoH0GvPKttpFM0OlYg8rruCWpfhzVLo7DAx1cBWuq6JRDzkJrDSeT0wb8f/RBX0 8jYcAzYZq2AGdzV+ejSX6LoLmLOGgyG/D8q98T4iDtdd/PvgvZE0WoAAnFKgUghLZBtc6N DpwREaDCCus6p2UpR02Uif744OvwEV0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=odFBvwdO; spf=pass (imf15.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738208877; a=rsa-sha256; cv=none; b=lbyYWlcwNjsT+ANPXCjNmvH01VSLOODvXjK5s4MXMV8QGk4VEe2Cy5ymhSOA+WkdAq36Z4 f6pfOpNqi57cABsoAOfyBI/e8cXM48dndiTHXMfAy/wZicFDlIZQvQgfEdwwKRwC88w8k9 dPWYlQHiKMBb7CaQyq3crAIzGtINMVk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7997F5C5B2C; Thu, 30 Jan 2025 03:47:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EA24C4CED2; Thu, 30 Jan 2025 03:47:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738208875; bh=pIkZbvbWGUeN/Ycv3ABKfmi4ASKA6ChqmpXCdQeUA34=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=odFBvwdOAAzBJZk8fcRUPX7qQ3QWNXoz08ePhvdLVtcc/ajobd3vOdM+saC1Fsmon SFN0bGuySg7U9jqD134DY3goAJJPPQDTiTMVoQrolcZvcF/1bVqua/IDXAhbDJu/o9 Bvwe55RPaOK+DdfnNVtxEW7QoxVXo2tD905T+PFs5p58BjuLeiaiCxhDWqsFaHncGS Z4JkQOGX1ZmAOsL0OXjrXmOpAxA9kifl1Qb8h9QiokWbAck7voR+jAd16X2pIop924 uDEZpNvIteqSbkgm29EV3uOlHVCSRl8on3uoGgorLUSVMdG9w4FghbCFNwu/5QRfHL 30jyhX1nEPfVg== From: SeongJae Park To: Yuanchu Xie Cc: SeongJae Park , Gregory Price , 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 , Jonathan Cameron , Kaiyang Zhao , Jiaming Yan , Honggyu Kim Subject: Re: [LSF/MM/BPF TOPIC] DAMON Requirements for Access-aware MM of Future Date: Wed, 29 Jan 2025 19:47:49 -0800 Message-Id: <20250130034749.49417-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DF36DA0004 X-Stat-Signature: 364163xcyj5541etiimzcjfdaxgs7zj3 X-Rspam-User: X-HE-Tag: 1738208876-612111 X-HE-Meta: U2FsdGVkX1+TzzI3iCGXX31X76j1Pi1KXAi9Yz1NjN7UxhELxF5HVFmOk1op/lfdjSzIW/5wZJE2hATMN9kQ1F1UKJNQM6xYjn2AUJgcPSC82QZ9/jy95vogNW7SAnXF+6m/Ogjmuvic4E9BZprBiDFehlpbbAujyL+4/lcQ91547RXFWG/HW56nUFLxLjV7wy2Kf2cLZer7ozOAA7M1Pqh0gsO+bp/YBCU00VolK8lUsldEeldIAlmsVgJbTqw/NroEYIfMqxYBZ4o4t8u/wTuNEsDYsQ43bUoa+DbrG7VIiU0IYUNP9B+R+TE85SWaORjYAC1eoVCKKVaRB7H8OK9eAccddAA8TmYjEnI2blIwTZ3Bv7vtp80AzJdc/BoVuDl0bmWIq4fdbgmsCAaVubqLayNSeg4LmtwDy3Py20mUX36+t2W05kDXYbqas4L1XV3z/nirNGRFNUdm//Z0KufBxo2+tk31gro6o8MqUS84FVa4yMO6i7u0GBqy6o9znomSZOeOQ30Wj69f3e34mtKhiR+1ys2r3GjpprIzWRxE8z7QwsIf68sMpt2mu8O30eTNTNtj7i3J04H6+cv6JOKwAlRRpPNjHX+OPuO5sJQQ6zks6lQ2xvnhUFBTn7pwd63lt469VPWo2ey13D30FT07X4mUkV6bpJxWIBHn0cIZDWKOtX3zZLnJwcjrHpQjLclPwnRsbCzcpUTLuYnMleCWxyEO+yJtHw0/w8lJCc5O+IvFAr76GKF4omwy5RLai1w1/UfYnhdiGaBR6Lp3KSp3YHfiwfcM58gP56gBlFRfLyB3SEawRQaq6A6TWQSD+2OjGUiOKb+EcPeJiVNwIs3VonfbsugHDbFY/PLs/eWX7HzqnUvfmPP1vYAUZMJbv0TPbnbS55Y3YzKyJKvJ0YDY3RUqLytgACLoEJjwno6eem1y6kfkiiZGRF3E0QRChSGG+LoWZ5HbL7T9QdT G+8lo0P7 AnIMJbteqd3ZlyJpeHByLIwbCARmHbbOi02uRdW9Dj/nkmT7YzCY7B+rvhqDgg/0yGbTUXhWhodZukZX8mvAbCUAMaCKUBRDgifOFiY3EavZ2kiHIpDLHmLVO07xXyusegsbAqbLcot4PrXp4YnncRwqT1Qc4GEXKYu7UiZ8U65O1oYcHwFR8IAfGoH2XI2eXt9EbBOvSflKWYjTonHTm91VgCSAoAlTLkTW39ugyuAcC5uaJ7KYT0LMjmOuJgp/Jg/cHlhlTR89GJkbZHc2BTPpotPhTqqPWur98hNZ4tixdt3jrcMJggYPJ4Y2iSrnbXc+FPEFtY/i0oZprnXsxbIdXUn/gy7P3REKN 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: Hi Yuanchu, On Wed, 29 Jan 2025 18:15:08 -0800 Yuanchu Xie wrote: > On Mon, Jan 13, 2025 at 7:06 PM Gregory Price wrote: > > 5) Scarce resources > > > > We need to be careful not to consume excessive amounts of resources > > in an attempt to track all these identifying mechanisms. Even 1 byte > > per folio is 256MB on a 1TB machine. This gets out of hand quick. > > > > With task-work, I was able to add no additional resource consumption, > > but deferring to a fully async scenario and needing to track things > > like last-accessing CPU, timestamps, and etc. > > > > We'll need to examine this closely if we decide to aggregate either > > of these mechanisms. > My concern with physical address space monitoring is fragmentation. I > ran some numbers on a few prod machines. Grouping by regions with the > same memcg and ignoring any unmapped memory to be generous, machines > with higher utilization can have a region/total pages ratio of ~40%, > and even those with lower utilization (<50%) can also reach 20%. > Accurately tracking these regions would require quite the region > metadata, on the order of GBs. You're right, if we need page level accuracy access monitoring and want to use DAMON with its regions based mechanism for that, the memory overhead of damon_region could be high. That's mainly because DAMON's regions-based mechanism has not designed for such usage. It is more for a best-effort tradeoff between the overhead and the accuracy. Regions-based mechanism is not necessarily the only mechanism of future DAMON, though. If there are use cases that regions-based best-effort accuracy cannot be used while exactly the page level accuracy is really required, we can think about optimizing regions based mechanism or developing new one. But, IMHO, the page level accurate access pattern is not always essential. In many cases, being able to distinguish some amount of regions agains others based on access pattern is practical enough. Indeed, DAMON has been used on real-world products with physical address based moitoring mode for years with no significant problem. Also I think physical address space based monitoring results[1] on a real server workload that I shared recently seems not very bad. Of course your use case could be different from what I have experienced so far. I'm curious if and why you really need page level accuracy. [1] https://lore.kernel.org/20250110185232.54907-3-sj@kernel.org Thanks, SJ