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 4E241C3601E for ; Thu, 10 Apr 2025 06:28:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC87F2800D3; Thu, 10 Apr 2025 02:28:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C77702800D2; Thu, 10 Apr 2025 02:28:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B40192800D3; Thu, 10 Apr 2025 02:28:32 -0400 (EDT) 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 96B2C2800D2 for ; Thu, 10 Apr 2025 02:28:32 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6A6C7AB968 for ; Thu, 10 Apr 2025 06:28:32 +0000 (UTC) X-FDA: 83317155264.10.C17DB6C Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf17.hostedemail.com (Postfix) with ESMTP id 59B1040005 for ; Thu, 10 Apr 2025 06:28:29 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=zuoze1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744266510; 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; bh=zRBmHqw4iNgFWCoYUcbvXmD7jIlxVf0uRKOrLBEhN4I=; b=TGyL/VRxDZAmq4gQRmzwDT3r/WkgGzD7Qqd8qyZEjukCVZOqg31bRs1HwD9MQ0AGcijB3n JKT9phb5CQooqaHIlfQ5NMlp7eGCBgIC2v21QzNJTO+B/8gCbLlGDYMh0e5WR6l64vI7C0 SUuKHeydy2igLvF/WmHR3b4qAselKSM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=zuoze1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744266510; a=rsa-sha256; cv=none; b=D05HrOS5F0tLWD0WR/0KMlO5kpHWFuRdnFyFbcdCZAlw+LXU7icNYibnfOMCW+BRbK4bxw AyHJlNFGJfQwkyazBgpzqdaS4EbQUuSE3/LnhyzRCV+tL2jvu2AXNUs5SOhSC8/AmkSEqS FkZo3N+ckNuvDyjm9sAalSq7sOE/F5c= Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4ZY8rt4Mr8z1f1vX; Thu, 10 Apr 2025 14:23:26 +0800 (CST) Received: from kwepemg500008.china.huawei.com (unknown [7.202.181.45]) by mail.maildlp.com (Postfix) with ESMTPS id 7F9E5140109; Thu, 10 Apr 2025 14:28:25 +0800 (CST) Received: from [10.174.177.186] (10.174.177.186) by kwepemg500008.china.huawei.com (7.202.181.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 10 Apr 2025 14:28:24 +0800 Message-ID: <75e5f32d-a824-44de-b9b0-a2d58dc2c45b@huawei.com> Date: Thu, 10 Apr 2025 14:28:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm/damon: add full LPAE support for memory monitoring above 4GB To: SeongJae Park CC: , , , , References: <20250409173639.52133-1-sj@kernel.org> From: zuoze In-Reply-To: <20250409173639.52133-1-sj@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.186] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemg500008.china.huawei.com (7.202.181.45) X-Rspamd-Queue-Id: 59B1040005 X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: xngyaax8rediowsfwzmgcdys9gqwnkfc X-HE-Tag: 1744266509-439643 X-HE-Meta: U2FsdGVkX18+n1x3elR8qBb/+/5UrjPogHL21N6zBp2XeNq6WdNSVr38CpIygdZT8xFfa8T7ABFMPlJakAlkEhYvX25ep/vhhrLMBx528bfrrwhZvSCZYv/yhEOQLD6D4TePBTOQlbZbbPwbA6zopdSCITe0JIhaEZyTDWhVD5zj1qLzUucAaNxVpnfZ9fNxaxB97xByeAl0NEYiUglnWVDtOUDJfGBQ8Z9OSWAAhFhngfuCXO/pCEHTjv/UeRUyKKuqAM5KrnBTkpx0QBRC+bWmFEhceyeAa8MPE0QYHsh75FkTQ0R/b0Nm3C9OGE52IFp9gqW/4pdonz+zs8KXUEMLaeD7dwBZfiX6eLr8YvGsQsI7/SSZFACA3u/JNRzABLfwmRreD53aQxY9z6IHrg9C6gga+qTe8GUH4/FDXj+dCFry/2WBwMG7DJgqCwXb07FD13guFvlZiNL2duMX4iDMElxLL8K9kxBGXn9C95NtBQchr1DN4fJpn7MhXYWIYKhr8Ap6guAKQvSoCc2jyp4veoNSxPThOBYAmP2ap+HHLLpNpcfBNVzSeimkppGwhtUKJYieRJSytrdSja97Ki2IBzN0cmy9HDE3urKAL0Ps3eFe7kymfT+6Ll7JeUiRBuE3T/VmegrrkGUjPsMkWpX5IvnFSifm/U03fV2psq7GbGqEKZnpE6fgWSq5JJlpp5vrMxCv8af8wY2Rdt8WeOM/lqMxKZ4cCKcQ98xvi0hr5vd7eKcVrjgTZPoxVMV7xumzHM11WJsIs4MwAPypn1y/CxI+9JTd90bu4zU9PfhL327ptprBbSD+xU/DiqR0uCeatNYvRVLW5sQuj4qoofTPjVVkKngEuFR4HbIpn6wBw9N/nKGTUdjljJgK38g4WpzrPeJMCF7llCXQCyTyGNQCBxtj/uN8NGm2Wgtimp377yw9CmoCICEtbebeRcJ2moe8IE26mxy2myV4Yum xnx1tb88 FE1ZboqPdfynjIgLlzeFhmkK7x012+XctLS9PGgGVK7jZw9hXkQepi/ddY5GniXhCiYTjzR8BTZlPFvwmkXxtpRFJjihY/RSKNJvY5qKhW3plPW8e82FF9cWlv9P36dOJtQR4oj81cumH0M4P3sBf/W87h+a6XN/atZajViOp/dDSBcjSgX6fzfGLE9y7qf8SzXne/LBddgBg5CrNg67mPqZ9LA== 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: 在 2025/4/10 1:36, SeongJae Park 写道: > On Wed, 9 Apr 2025 15:01:39 +0800 zuoze wrote: > >> >> >> 在 2025/4/9 10:50, SeongJae Park 写道: >>> Hi Ze, >>> >>> On Tue, 8 Apr 2025 15:55:53 +0800 Ze Zuo wrote: >>> >>>> Previously, DAMON's physical address space monitoring only supported >>>> memory ranges below 4GB on LPAE-enabled systems. This was due to >>>> the use of 'unsigned long' in 'struct damon_addr_range', which is >>>> 32-bit on ARM32 even with LPAE enabled. >>> >>> Nice finding! >> >> Thank you for the kind words! >> >>> >>>> >>>> This patch modifies the data types to properly support >4GB physical >>>> address spaces: >>>> 1. Changes 'start' and 'end' in 'struct damon_addr_range' from >>>> 'unsigned long' to 'unsigned long long' (u64) >>>> 2. Updates all related arithmetic operations and comparisons >>>> 3. Adjusts print formats from %lu to %llu where needed >>>> 4. Maintains backward compatibility for non-LPAE systems > [...] >>> >>> But, this doesn't seem like a very small and simple change. I think we can >>> find the best approach together, by understanding impact of this change for >>> short term and long term. For that, could you please also share how prevalent >>> 32-bit ARM machines with LPAE are, and what would be your expected usage of >>> physical address space monitoring on such machines, in both short term and long >>> term? >>> >> >> Thank you for your feedback. I agree this isn’t a simple change, and >> the current approach might not be optimal. Let’s work together to find >> the best solution. >> >> As for the prevalence of 32-bit ARM machines with LPAE, these devices >> are still widely used in our product application. The main goal for >> enabling DAMON on these devices is to optimize memory usage. During >> usage, we identified this optimization point, as well as overflow issues >> with bytes* and other reclaim statistics interfaces. >> >> These devices are still in frequent use, and given their large installed >> base, they are unlikely to be replaced in the short term. > > Thank you for kindly sharing these! And I agree the devices could still be > actively used and wouldn't be replaced in the short term. I believe making > DAMON supports those devices is really important. > > DAMON aims to support multiple address spaces that not limited to only virtual > address spaces and physical address space but any imaginable case. I hence > prefer keeping DAMON core layer independent of the underlying hardware as much > as possible. I therefore still hope to continue using 'unsigned long'. > > Of course, 'unsigned long' wouldn't fit all cases. 32-bit ARM with LPAE is a > great real example, and there might be crazy future use case. In other words, > this could be identified as an issue of the operations set layer, which > directly deals with the given address space. > > I think another approach for this issue is adding a DAMON parameter, say, > address_unit. It will represent the factor value that need to be multiplied to > DAMON-address to get real address on the given address space. For example, if > address_unit is 10 and the user sets DAMON monitoring target address range as > 200-300, it means user wants DAMON to monitor address range 2000-3000 of the > given address space. The default value of the parameter would be 1, so that > old users show no change. 32bit ARM with LPAE users would need to explicitly > set the parameter but I believe that shouldn't be a big issue? Regarding the address_unit approach, I have some concerns after checking the code: 1. Scaling Factor Limitations - While the scaling factor resolves the damon_addr_range storage issue, actual physical addresses (PAs) would still require unsigned long long temporaries in many cases. Different system with varying iomem regions may require different scaling factors, making deployment harder than a fixed maximum range. 2. Significant Code Impact & Overhead - Implementing this would require significant changes with every PA traversal needing rescaling, which introduces computational overhead. That said, there remains a necessity to use unsigned long long to store certain variables in structures, such as sampling_addr in the damon_region structure and sz_tried in the damos_stat structure. If I'm misunderstanding any points, please correct me, and feel free to add any additional concerns. As an alternative, we could adopt a pattern similar to other subsystems (e.g., memblock, CMA, resource), which define their own address types. For example: #ifdef CONFIG_PHYS_ADDR_T_64BIT typedef unsigned long long damon_addr_t; #else typedef unsigned long damon_addr_t; #endif This approach would avoid scaling complexity while maintaining consistency with existing mm code. What do you think? SJ, I'm happy to help test any approach or discuss further. > > What do you think about the rough idea, Ze? If you don't mind, I could > implement the idea on my own and get your review/tests, or help you > implementing it on your own. I don't care who implements it but eagerly want > to make DAMON supports the real use case well. > > > Thanks, > SJ > > [...] >