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 C4707C0218A for ; Thu, 30 Jan 2025 04:11:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0570C280084; Wed, 29 Jan 2025 23:11:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEDBC2800B5; Wed, 29 Jan 2025 23:11:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C03262800B8; Wed, 29 Jan 2025 23:11:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8E59F2800B5 for ; Wed, 29 Jan 2025 23:11:45 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3EBAD45F37 for ; Thu, 30 Jan 2025 04:11:45 +0000 (UTC) X-FDA: 83062794570.17.C9429AF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 7D7851C0005 for ; Thu, 30 Jan 2025 04:11:43 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FvFPOePl; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738210303; a=rsa-sha256; cv=none; b=B3OljPRY8SHR9Am4ky+yXdSJnhJAKdXBaHryh21aWINavSKKcm9FsSbMD1HljQsZtvww70 OXHQO711KVgBxMub4ooT7SEyRD9fb92snbZvoMQoQbTKDxufLv91H1LnC1bMDzO0p/bkC6 iMf0wMjbk3Ntajxoofr+/6yevuj2PAw= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FvFPOePl; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738210303; 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=z/UWYY6h8XzOxVdVLZle7I+sg6M5EKTdQVxbauy8GkQ=; b=cPFYz1MStdRP4zOKZX/KYvUN2byDKzUU5rWIlTg9AmTXR1tbhm9jlkUcQQguVJHf9b8jn6 ZxOmMpHUOzFqv8mzHSZ9EmOQPtbUAzZvMPj1aJEgyawelyMRO0nRBhCRWXTwBLoo2EZ103 xdzGG8G2CEZP+mD04m8vDqmCDFqxTxg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A13825C56B5; Thu, 30 Jan 2025 04:11:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 142C8C4CED2; Thu, 30 Jan 2025 04:11:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738210301; bh=UC8IeBBKFfPBafCFr4kyUFlVe382D2VnfBipiZRaeRk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FvFPOePlZwb+q7p6VAdWvFNtAW3tP1nHg6WW2zcJaU4NBd7tkRrFawMA/8C7BVKNG avNXIc291RJYKtb21lcaVNzFUTmGc5vV1aU3QRNrNmu8Q1jLa4VXBHSzRiYuAPZv1l gzi3AAm1a55/2ZTre2qX6zQBFJKDzfm5yJc9JKoT6RZNMwmr4U2C1a4zYCTEJ6R7b4 ZR3IOq9yYN4nJGJGt4UWdBiWuXACHW9fk0T1xLslstiVWWKaN3EMcatUlLBePbEL74 udgZylVrsFyKyefsc0ConnfYje20wF64jkfAOJtPMg6sLxytwIat3xeR8ynGMZJpGt lnapa7ShDYaDw== From: SeongJae Park To: Yuanchu Xie Cc: SeongJae Park , "Aneesh Kumar K.V" , Khalid Aziz , Henry Huang , Yu Zhao , Dan Williams , Gregory Price , Huang Ying , Lance Yang , Randy Dunlap , Muhammad Usama Anjum , Tejun Heo , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Jonathan Corbet , Greg Kroah-Hartman , "Rafael J. Wysocki" , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Mike Rapoport , Shuah Khan , Christian Brauner , Daniel Watson , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v4 0/9] mm: workingset reporting Date: Wed, 29 Jan 2025 20:11:39 -0800 Message-Id: <20250130041139.49594-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: rspam04 X-Rspamd-Queue-Id: 7D7851C0005 X-Stat-Signature: 93wabm6d3dhxjuzto8fdycfsfsusatzd X-Rspam-User: X-HE-Tag: 1738210303-427406 X-HE-Meta: U2FsdGVkX1/c3J3nLA/cM/pNtgBTkkdKTpUpCnjPOT6XigkhqMYpjG/lmlqDTyR6017EhUv8MjqRX/yIsPSFR3VqwU4uYwTIlzE/7SBzLwrnOBXORMwF/wpdcJBJh/Xv/MzTMf5mEtpQYNYoNHc1j5kjxkKapQL/HxMqmqafgwH3jpTRCEaaSA2SPVLKksrldbBFe7PTPy8lZtb7MzbbYV2f0aRyOigae5x5Chc/nBZV2cuKDo6oLqOc9c7wOcg6WkC7zCmuLkPnHwlfBGOUmZVC4DAC9RYG5i08BAQCsnv77hl+Mv+xWRY/W2zBsfY7ubrbEVwUVqSJpZalgposJCnp2pBvb9Hi0HHd/eHyrJAK2BIvuRiZuRhsixWaLjQR1sXTSXlVfF7cclA25GFmhx3AdXytW5iWKznGZuRQyXuQ2ETUgY6SRT+b3xltSjC783VL2L6t3IY4mgIxmWBdDyQrQqW2TKyIT3mz1e54DUNzUmrX8J8rmbGZga9Geq4pKsksvvCT2yEH5nZfQNrry44qMRRBNLvfjyGNBHv6V8n8zibeZjdv/TcpYE5pY2II1kUOpABgVirYslaLzKjXp4WLNLkETeAsq+c99A0Dbw12kRO5X2NQXEPhzO0ehCXaydSeepfJAlya+6Hr7Qc2w7n8t106dhTJz+U87rqjqELswzZKK65lf17c8KVKechln93xiTwHFUeFax+1xmP7Qpxf+Kn/MPUUE7CKlhf6TxlS6l4dgsydEXY9zeul66/NyfEfusTW3x6D5m+TYAjbDJqRrqZA7gofBhMI9etCbEXrfh2VBndo+IUdxmradnI2ODvYH5aNCw10V6wwsoxVEaAGluNxSjQaSmxSqpBTKNpYtlX/Um8Mgm9Hom2GtZC3XPNYrvA2zlUB4w5eqfsvRfxFK++Yei0mG77p+oN6EtfwKEfxLbqgI1bwiejCwocrsiAnUnb6l9v3me2h84c xaanC2Gw mE9q47Qf1zh/W1+mlJ70/dJrXyPfR8w6NLZk1z/rNqeH2m0ThbmU0BFS0wWi7snmZ7aiSQ2lHndcEI9u6v1baCIMIDz7qM0mBQgNMERInutlajbgYzcIWwpnpoFn0C7qxfQ9Cgetx8psmOO+wd2FUUqlydqufunTSPhUGQoalfoWOC05FsSJ/Iy6wraSTYOdCC70HQpuXaFCExU9GK8KLhpgyzD3OCDE8nE+uzz2RRQOvV2fMsY2HGpUsdcRXafQLzpY5flPMhxIY9/JvkNG95/eoInjEyYr5QeIfARu/TLetYDqjUU+/PlKJv4RJaxDg46pqEB4lIg9ziO677hqdegZUacAYJKm6+Fi3 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:02:26 -0800 Yuanchu Xie wrote: > On Wed, Dec 11, 2024 at 11:53 AM SeongJae Park wrote: > > > > On Fri, 6 Dec 2024 11:57:55 -0800 Yuanchu Xie wrote: > > > > > Thanks for the response Johannes. Some replies inline. > > > > > > On Tue, Nov 26, 2024 at 11:26\u202fPM Johannes Weiner wrote: > > > > > > > > On Tue, Nov 26, 2024 at 06:57:19PM -0800, Yuanchu Xie wrote: > > > > > This patch series provides workingset reporting of user pages in > > > > > lruvecs, of which coldness can be tracked by accessed bits and fd > > > > > references. However, the concept of workingset applies generically to > > > > > all types of memory, which could be kernel slab caches, discardable > > > > > userspace caches (databases), or CXL.mem. Therefore, data sources might > > > > > come from slab shrinkers, device drivers, or the userspace. > > > > > Another interesting idea might be hugepage workingset, so that we can > > > > > measure the proportion of hugepages backing cold memory. However, with > > > > > architectures like arm, there may be too many hugepage sizes leading to > > > > > a combinatorial explosion when exporting stats to the userspace. > > > > > Nonetheless, the kernel should provide a set of workingset interfaces > > > > > that is generic enough to accommodate the various use cases, and extensible > > > > > to potential future use cases. > > > > > > > > Doesn't DAMON already provide this information? > > > > > > > > CCing SJ. > > > Thanks for the CC. DAMON was really good at visualizing the memory > > > access frequencies last time I tried it out! > > > > Thank you for this kind acknowledgement, Yuanchu! > > > > > For server use cases, > > > DAMON would benefit from integrations with cgroups. The key then would be a > > > standard interface for exporting a cgroup's working set to the user. > > > > I show two ways to make DAMON supports cgroups for now. First way is making > > another DAMON operations set implementation for cgroups. I shared a rough idea > > for this before, probably on kernel summit. But I haven't had a chance to > > prioritize this so far. Please let me know if you need more details. The > > second way is extending DAMOS filter to provide more detailed statistics per > > DAMON-region, and adding another DAMOS action that does nothing but only > > accounting the detailed statistics. Using the new DAMOS action, users will be > > able to know how much of specific DAMON-found regions are filtered out by the > > given filter. Because we have DAMOS filter type for cgroups, we can know how > > much of workingset (or, warm memory) belongs to specific groups. This can be > > applied to not only cgroups, but for any DAMOS filter types that exist (e.g., > > anonymous page, young page). > > > > I believe the second way is simpler to implement while providing information > > that sufficient for most possible use cases. I was anyway planning to do this. I implemented the feature for the second approach I mentioned above. The initial version of the feature has recently merged[1] into the mainline as a part of 6.14-rc1 MM pull request. DAMON user-space tool (damo) is also updated for baisc support of it. I forgot updating that on this thread, sorry. > For a container orchestrator like kubernetes, the node agents need to > be able to gather the working set stats at a per-job level. Some jobs > can create sub-hierarchies as well, so it's important that we have > hierarchical stats. This makes sense to me. And yes, I believe DAMOS filters for memcg could also be used for this use case, since we can install and use multiple DAMOS filters in combinations. The documentation of the feature is not that good and there are many rooms to improve. You might not be able to get what you want in a perfect way with the current implementation. But we will continue improving it, and I believe we can make it faster if efforts are gathered. Of course, I could be wrong, and whether to use it or not is up to each person :) Anyway, please feel free to ask me questions or any help about the feature if you want. > > Do you think it's a good idea to integrate DAMON to provide some > aggregate stats in a memory controller file? With the DAMOS cgroup > filter, there can be some kind of interface that a DAMOS action or the > damo tool could call into. I feel that would be a straightforward and > integrated way to support cgroups. DAMON basically exposes its internal information via DAMON sysfs, and DAMON user-space tool (damo) uses it. In this case, per-memcg working set could also be retrieved in the way (directly from DAMON sysfs or indirectly from damo). But, yes, I think we could make new and optimized ABIs for exposing the information to user-space in more efficient way depending on the use case, if needed. DAMON modules such as DAMON_RECLAIM and DAMON_LRU_SORT provides their own ABIs that simplified and optimized for their usages. [1] https://git.kernel.org/torvalds/c/626ffabe67c2 Thanks, SJ [...]