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 9423AC36010 for ; Fri, 11 Apr 2025 06:30:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63D05280175; Fri, 11 Apr 2025 02:30:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C2CB28016E; Fri, 11 Apr 2025 02:30:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 461B6280175; Fri, 11 Apr 2025 02:30:47 -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 20A6928016E for ; Fri, 11 Apr 2025 02:30:47 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5AAD481E68 for ; Fri, 11 Apr 2025 06:30:48 +0000 (UTC) X-FDA: 83320789776.19.20A51E5 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf07.hostedemail.com (Postfix) with ESMTP id 9146B40004 for ; Fri, 11 Apr 2025 06:30:45 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf07.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=zuoze1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744353046; a=rsa-sha256; cv=none; b=ZJDIvlXNQX57SP7WI+reKMcoY669J0CJipxnQEE2vqzDB2wuIO4oLgQwT8oKUqjdzaLY/0 E517RitiLqSjX62JbV/po6ftUfnBHbec227FojxNw4aBDyz2AYpPig7qo2HQ2DpdC3GB1q SRISo9FLaFqsEEmFHGuw+1U/OoV5b6A= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf07.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.255 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=1744353046; 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=0baR79yZBxHHnzWVblGknzQGRMMRcDeQ15gYCZ6t6k8=; b=GgPDWOOjI4tLdmyAftfwS16Pw+vMjwcznHg33Xk8/2xnf4HpBMLZLN6FAC8pjoKpZe6G+8 JnEkLiN1j1N/tw1g+wkkQZgsF++ZV8Mcv4RZxiL5c3wmlMrJYpnI6rHV4z8hl3mlbYZe3z koRplT5ZNKonPsYDCmaVd6grVnaSTzY= Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4ZYmxy3Q8yz1d0sk; Fri, 11 Apr 2025 14:29:58 +0800 (CST) Received: from kwepemg500008.china.huawei.com (unknown [7.202.181.45]) by mail.maildlp.com (Postfix) with ESMTPS id 97D291800FE; Fri, 11 Apr 2025 14:30:41 +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; Fri, 11 Apr 2025 14:30:40 +0800 Message-ID: Date: Fri, 11 Apr 2025 14:30:40 +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: <20250410222507.56911-1-sj@kernel.org> From: zuoze In-Reply-To: <20250410222507.56911-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: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemg500008.china.huawei.com (7.202.181.45) X-Rspamd-Queue-Id: 9146B40004 X-Stat-Signature: frso7rfseom6q4d5c8dgk8jkdr9c13cw X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744353045-123239 X-HE-Meta: U2FsdGVkX1+ur6einke+ddaBMder+tPT6v6Z8GHOi3Mi1VmpPDjkwVPBsKVGnFquOcCtZV4+VzPU31Y9nYj9UG1PeyFNkj5xRwZxrNGe6B5TAw2wo7b84U7Ok2xIwxOX5WJcOy/aGujKPyOQvtKTiNl/R9XEucc5vClwcXqw20IjEH6oaJThgVKF1FvsWi5a2AB5swF39tGA20VadrK89qHTxn6OAff9Hm7XXjcdxmYeFHsovbFH3p2EPTS0aB5e3JmCRk9MO7zKY7gUBnCIN4/KYg2voGOKmtKUxPC6lSOMU4slvC9sTl5Ym213+Js+nEMkk+xLVc1ju/CwVi+UD17Xbww2vUq1gbjVG22JcEDYE0MAjKhREyjV/GA7ymwna95fB4G3akDF4R9cVeVIfjpMxfpKOjfqSOsWUqplUYnudOOCdclzEeAoHKmCQcLQmw4dUbLZ3w/VNC88JJ9VoRYk6MHKcdS8orLV5+mdSWHiKHT9GideZRGeNr24KYbjCkna4C5/oFmJBXN2/TAPWxrV7pqFnpmLJ6v1MtYlXStxuvntpKRrYoaCC3PK+KIadBWNHzhPMR7/CHZVMf3sz2cG7/NSnSINXH/JOfNoZeCAl1G1ds28SIVcdOw+OQyJflulVc8OMyCgT9iNNdADlRhLtkpDoAEakZnjJbZmcTGZeyXm/58hse7Uvle5EvdqgCafsIussXvC6OxTIS1GYYxWj497eXD79oyTQBjf9fz0aQgBIo+5+CPurcP4fj4SuGST4U9KCtaFyREbfTGB6e26a46myLyBktCSyBPk+z9L4MVMtJzW3JwiuC2lc2rjjVqvO0NDfxvrqceOmFfuaUtC3rfVHDd0syMaqLqfMTkFv1BXKJRCfVfANJIIbRSdCrhkzVicbf+KfdraSfL5tnvVfTdg0XcEOgx0yXLmsx13VJ9OJP57ty5j+HmU5eUXCAV/mkn/ehIQ3t7J33G i1GSAWzZ D0kj4W8FQUjoZGy9Kb9x23m2lJnIr6aqX3bHZRr0alt8zKPjeBg6aYjtfTfVlpSY66vnxux5I7zCnQkWOmegq2b7zmXSXk1N9n8ISK7Avb39LElHzmPrwaV1qruy2hsZ7gNPFd1JxdWWPji9XhUF4F/JnEFgHTyyb+VXcOIt8vg/n3UeP7+K6dJMljAz8DMfe8GtoHZcKQNJ3bLJT1wEZiGgPWQ== 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/11 6:25, SeongJae Park 写道: > On Thu, 10 Apr 2025 14:28:23 +0800 zuoze wrote: > >> >> >> 在 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. > [...] >>> 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. > > The current behavior, which is using 'unsigned long' as the type of the real > address on DAMON operations set for physical address space (paddr), was just a > wrong approach. 'paddr' operations set should use proper type for physical > address, namely phys_addr_t. > Agreed. Using phys_addr_t for paddr is the right approach—unsigned long was incorrect for physical addresses. >> Different >> system with varying iomem regions may require different scaling >> factors, making deployment harder than a fixed maximum range. > > I was thinking the user space could set the proper scaling factor. Would it be > challenging? > Since memory ranges vary across systems, different scaling factors would be needed. This could increase maintenance complexity. >> >> 2. Significant Code Impact & Overhead - Implementing this would require >> significant changes with every PA traversal needing rescaling, which >> introduces computational overhead. > > Right, no small amount of code change will be required. But those will be > mostly isolated in operations set layer. > > For the computational overhead, I don't expect it woudl be significant, given > region-based controlled and minimum overhead design. > > But, obviously doing some prototyping and testing first woudl give us a better > picture > Agreed. Some prototype testing would be helpful to evaluate overhead, especially in extreme cases with large numbers of regions. >> 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. > > I want the core layer to continue using its own concpetual address type > (unsigned long). sampling_addr and sz_tried are core layer's concepts, so > should continu using 'unsigned long', while operations set should convert those > appropriately. > >> >> 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. > > The example cases directly deal with the specific address space, so their > approaches make sense to me. Also DAMON's operations set layer implmentation > should also learn from them. > Glad you found them helpful! >> For example: >> >> #ifdef CONFIG_PHYS_ADDR_T_64BIT >> typedef unsigned long long damon_addr_t; >> #else >> typedef unsigned long damon_addr_t; >> #endif > > But in case of DAMON's core layer, it should deal with arbitrary address > spaces, so I feel that might not necessarily be the only approach that we > should use. > You're right, this method is not the only option. >> >> 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. > > So I still don't anticipate big problems with my proposed approach. But only > prototyping and testing would let us know more truth. If you don't mind, I > will quickly write and share a prototype of my idea so that you could test. > Sounds good! Please share the prototype when ready - happy to test and help improve it. > > Thanks, > SJ > > [...] >