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 76F4AC3601E for ; Thu, 10 Apr 2025 22:25:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A02F2280140; Thu, 10 Apr 2025 18:25:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B067280138; Thu, 10 Apr 2025 18:25:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89D83280140; Thu, 10 Apr 2025 18:25:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6B991280138 for ; Thu, 10 Apr 2025 18:25:12 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D97CF140FF4 for ; Thu, 10 Apr 2025 22:25:12 +0000 (UTC) X-FDA: 83319566064.16.2F97C97 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf02.hostedemail.com (Postfix) with ESMTP id 30CC380006 for ; Thu, 10 Apr 2025 22:25:11 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MOYYI1TY; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744323911; a=rsa-sha256; cv=none; b=fqAmqttP3FblyAyoqr9nRjkIwyX943qFSF1IHw7uNo1uUffK9BY9Bgq6nfQ2egnXIZTouF 82fu6Td5L0cFXA2nJPh87LGTelRMaldB/PbWJx1FT4CDuQR4AfhqSCD4yQRaUI5yg9hEAc jHbrr/jQkxVC7PbxyC3qTk6g71JfHKA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MOYYI1TY; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 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=1744323911; 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=1NdVYlYL/iF83k+K24SGHetKD2w78LWF85Dyai281hc=; b=PdxE9qw7Tx20DcVo37YaUTWLz7WkRjAyHWT58Fzeh50PD3XV0gegjgu9CUFNGZ1uCEV+fZ m1p+hwHRpcNy1uAsR9SZeQmA0t9K0TIFJ6Wms+DmcRJS/Gh5bm8FXDbazD6bMGYvNOC12E 8rX6Xv8IsndJ4JHZf8q6vjiSsv+j7zI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8A7F3A4AA52; Thu, 10 Apr 2025 22:19:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BD27C4CEDD; Thu, 10 Apr 2025 22:25:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744323909; bh=04ZPtX3eXEebxQjDnxpW8aE/sotN77rxW/2eO5XyZEM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MOYYI1TYkLvEr1EcRrzFAKQeJR/LHWVDUdkTfW4Th7xtBDbhtF7PaAfDSioPVuSqC S0RkcJU2iyN4fBnywfdVE68NezmnbXVcbDvKCCEZ3CqkYc4V0GwcoylV1qC8J72N/6 UdCz0fifthYDLna/AbAPQJtlCQ7Wy08keUlWeWll/E2/9YqvxwlRpYaDPyUxZLYUOk wNAZmdRRpcEGxTfsm7DBb0+3DUEhASQQIV5EdowZNG5c1hxvHSiQFF1p/VXPMumOUk F53Am2iVSPyi7SGRabBEnLxjYe0SbT1oQm5GMwA7EzFIid2B+PohaGkkiT//RhvcyG gERmaGST0kqyg== From: SeongJae Park To: zuoze Cc: SeongJae Park , akpm@linux-foundation.org, damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, wangkefeng.wang@huawei.com Subject: Re: [RFC PATCH] mm/damon: add full LPAE support for memory monitoring above 4GB Date: Thu, 10 Apr 2025 15:25:07 -0700 Message-Id: <20250410222507.56911-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <75e5f32d-a824-44de-b9b0-a2d58dc2c45b@huawei.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 30CC380006 X-Stat-Signature: urd1zqexdz6gbd66ab3aa4pn5dw8j5nm X-Rspam-User: X-HE-Tag: 1744323911-278653 X-HE-Meta: U2FsdGVkX1/s/s3AP2AF43njZxgpWIHbwr34Ssu9YJfQj3bRODmMrFVNRCGQKJ+2icwmhTgspljxBY4Ng37qE/85abV6Mt5BImCYTAy3PiSYTCuTfeM6Ix7Q6LC/kObBapoSwLAqsYPL9CV97haRAe5Gm370LB/XeFFm2FHUluFzudBQ64nzCa2G3WDKM34fCw/fbIHrColaYo2RJs8TFLM0pcQINpMUDZS/EoziZHWsEDRvOObxZy+O4/FywQDbd81LgXbLX1RCpFsuhjXybEERnFofxcc+DvbkF6yaC6Je/zcZwrvq3uYUPl/RDf7eIKDBMsiFYGrZ+LaQPxsm8NTaIiCJMc6BiHnhqYl/YJZFHcks1hwalDPnxadJNx60K3buj7Tlx81LPnIQQuz8X35hvOZ5tiPVLn1HWXDtcnNXedo2BtVa9TLdGex8skhxSRvw14INr/A293okXrDJI7OsAGsx5IX2pkyomzjVolIdzx3soJwMPCRFkRTKr1g9U9FQZBr6elI38l2Fy2RgyxsUrU0P3CyaW82fCLJ1WL0It0GWmeLrGNn/Lz2FauK0wq5ortYkkkf25qbByf9vzYYcDqrTmolhAfgbkwBMXBGGoitN7q/uVvbrljQYbzZ0pselYzzTPj1s72A/Q9TPFjofixI13UAmocctcOnN+aiPh0eB44yzNM+S6b2XTVS2NQutZefKXmnSkyIGlIW15uQhA6B4VEcVVNLh8ijUL2LCSZoM7CYDcjelK5bN+9wnWGtmmLGb154FZ3KcMJa2dS7pGM803tbE7A+alLAsilMMzk3QEWdayvUweBa63Fkiws12kuDNE0Mup9lHMOlxmcl9Lh8q1hS4ABqzGPK/dyguZZSekNg3HCNvvLuhZ+HRz+JMVbAr4WqYHv7Q553BbjXpP6n0LkSlWWNM7kvVs5CGM1oV9IT5TcRjr6lWpq9mX12OzmJcfcKJb1l3H3M ODU9QKcQ NyJsGMriZ9x+VemTv6/2lTJt5VN+yor450wCR4TTO3SZSshg8/NomUrfWHqH66oax8Ra0JfjkHQu3g+hCDDam7sikonDcIPi4FZ5U1UkpUObPsdbSwpYd2gbqiJh7SPj1zW/eh0JtKgdOyeZXJljvhrIGyY4mh2HmNGEo96YbDoBCQo615ycAg44KUo8xvHgms10J0YOK5A5kzpNRvWZmUKGKKDiAIG5zE93Fa9yPhNywW37kHJV60Hp+fO29ctKOxBzHyBUdjTwXfgA= 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, 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. > 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? > > 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. > 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. > 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. > > 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. Thanks, SJ [...]