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 878F7C36002 for ; Wed, 9 Apr 2025 07:01:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 956B228004B; Wed, 9 Apr 2025 03:01:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 906C8280049; Wed, 9 Apr 2025 03:01:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F3F928004B; Wed, 9 Apr 2025 03:01:53 -0400 (EDT) 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 624E9280049 for ; Wed, 9 Apr 2025 03:01:53 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DE52CB092E for ; Wed, 9 Apr 2025 07:01:54 +0000 (UTC) X-FDA: 83313610548.20.F0E363B Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf16.hostedemail.com (Postfix) with ESMTP id 3FA6F18000B for ; Wed, 9 Apr 2025 07:01:51 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=zuoze1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744182113; a=rsa-sha256; cv=none; b=TeJYk56NLU0Hoj6pwSf9j28eRjf6pruWH1sED5GU6zGPff4gZ3uFpFKtN+cjJzBNdrIfVp Ymc8Gv8gzE+wR2F/38HiUEDsLs545La5Dg249g4EoawqOCyA9OoP/9tmixmoK2fF/q8m9u BdjZxQCBtHmla/QO5bzXst/wuz94zVE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.187 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=1744182113; 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=O4E89P5VoA9fZ5F4mo9wO+p/Tmr+Xy7COwC8GeOqej0=; b=d+gxCnJJQT/sXe7GBU4JI+RVnmLRiZRnIChLL5l3Vfksjyr+LQXe6axgJeRueFU4arvoC8 hKoyhphLKlm4/KjzsStCMHAajo0dVA5K+DY223lVvsRGqlv8bZYj5noCsHxRLgm8XWmIQ+ HZNR/k1qpthUuL11sj3b/PjbfXAq0hs= Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4ZXYkq556jz13LQv; Wed, 9 Apr 2025 15:01:07 +0800 (CST) Received: from kwepemg500008.china.huawei.com (unknown [7.202.181.45]) by mail.maildlp.com (Postfix) with ESMTPS id 6DA5D180B4A; Wed, 9 Apr 2025 15:01:48 +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; Wed, 9 Apr 2025 15:01:40 +0800 Message-ID: <0e82b335-09ce-4a0d-809e-f55405ac7953@huawei.com> Date: Wed, 9 Apr 2025 15:01:39 +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: <20250409025036.70633-1-sj@kernel.org> From: zuoze In-Reply-To: <20250409025036.70633-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: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemg500008.china.huawei.com (7.202.181.45) X-Rspamd-Queue-Id: 3FA6F18000B X-Stat-Signature: nx33ciacmfccd43fjnsqsbgz3hng3jdx X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744182111-524232 X-HE-Meta: U2FsdGVkX19iAA4wtk1paZVHPAK5wGY9EXFf2d4b9n9xdVjKIcoVTMPO4FcWrYvrhiP3tWujblN9O8CuCyVDbSkPD3Zc7XuPIGGxVtYYk50fUO83JeNj22vu6HvNLvFP7GoHh9Rh7PIY2Kw1ZxYdBljf8jvFNXwY5fOTrq+0bU65MDA+IR8WffPO/DTjZp31s1PWN0LFBZ2sjKrezG6p/YNeL5dPHf8cnsWTuojB5etDrREuBen6zpRUxPJ3Ip6xnGtzgeE5cMFjWAo7eggF5YNi6mPSJx11hhLcvx68y7qsf4WdkIPWiuOGyws7uFXLf5mX7cnFQJv+bqC/9JWP9z1MRXWdr7FdP6i0HNjm0I/iweNZD/uNBqTslxDKthWzRy/TUxaFIiGIA5eVSZzpn3r0vZqR/DDKToQO71oZF4vkdtivwa+5sQbuwuW5Ej/z/zKox/HDRgTMJK7ZOLF9CM6xFNb13xzanQPf9kx0esFzxEPYuM6wfWMnMltzwNOJ2w00ofk2O3SXMQmBEkqpm33PMmV6SRU2hQX+xluUEzuXoaATBltSYdhWx2uez7oGx4ljPnF80/NPBh/cIUUVo+cbb6ZPbNsgCalt3TaLHjeoc43dWhVlSp0pf9zHUlrV0JADgsXXdb6xKKxqMKtliMf20BQpCt0kCT9jq2v6yXPdW0kDDpPNTsxs6z0YYaoC3HXO3xOj6+BcA25bP7dOFjDOUWtTB2Oi+xUHg9WhcroTa76N002XR3fOtbhdZUfMTZ9u0VrSgO4ONYkOkPVrdse9rPa5d8pw9Zqg8z8D/eXjlPUyomR+XOhFU7uY0AKkGucEFhpgITYR3JyUBJJMPFfsciRtp5Gs8PEBX68eRoOfUwuZDtyMWyj+jbGnXYOEE2eFNYrxBTpZyNaupAa/Zfp4qbPR7P+/BSglDmPcsoPFYaDOdVChTZxV+Ex7ixTSvhgI+u5NgUBCPiGiHMT 18T8GduC GSREU4E1FJR9+I2MzLEgLVPhQzsHNKy84LlRxeo5OSSrM72Z54myNdlKPMZiji8MkO8u5qKRAY8ba06LbEsjkTarTqZEkigbnYfNNcFyFDl1/Ta1rpoNZ0slzF0mfeGAnboCcVrqM4h9QvSsob3TcU0FquxLVPekHDMB/bSMO26xgDmOtMCdPloGaYMtcn+5J48CTBaS0bFFlwpZBNRKGjoVfQQ== 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/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 >> >> Since the overhead of always using u64 is negligible on 32-bit systems, >> should we prefer this simplified approach over the conditional typedef? >> >> Alternative implementation approaches to consider: >> >> 1. Introduce damon_addr_t that adapts to CONFIG_PHYS_ADDR_T_64BIT >> 2. Convert all DAMON address operations to use this type >> >> Just like implementation: >> #ifdef CONFIG_PHYS_ADDR_T_64BIT >> typedef unsigned long long damon_addr_t; >> #else >> typedef unsigned long damon_addr_t; >> #endif >> >> This method could potentially cause minor issues with print formatting >> and division operations. We'd appreciate any suggestions for better >> approaches. Thank you for your input. >> >> The patch change allows DAMON to work with: >> - 32-bit ARM with LPAE (40-bit physical addresses) >> - 64-bit ARM systems >> - x86_64 physical address monitoring >> while preserving existing behavior on 32-bit systems without LPAE. > > Again, nice finding and good improvement. Thank you so much for sharing this > nice patch. > > 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. Thanks again for your insights. I look forward to working together to find the best solution. > > Thanks, > SJ > > [...] >