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 10E2EC36010 for ; Wed, 9 Apr 2025 02:50:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4EAC280040; Tue, 8 Apr 2025 22:50:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFDA228003C; Tue, 8 Apr 2025 22:50:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EAD9280040; Tue, 8 Apr 2025 22:50:39 -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 7FC9228003C for ; Tue, 8 Apr 2025 22:50:39 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F18D61219D5 for ; Wed, 9 Apr 2025 02:50:40 +0000 (UTC) X-FDA: 83312977440.19.656EEE9 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf01.hostedemail.com (Postfix) with ESMTP id 66AFD40007 for ; Wed, 9 Apr 2025 02:50:39 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="p/05zKN0"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of sj@kernel.org designates 172.105.4.254 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=1744167039; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qt7k66wXqSRcHeM1fqdet6OiioggZQl8w8NOYilTxgw=; b=MNMLciSf4pn72+OMd1LvgkOaheBiZYSAuWjtzG2oPdJpLy8P+PVsPEp3mXcgeKMcKIw2Ya yPU3JGsKOMKGn3WI+kHckO91gU+2OcHHjm4yk/zSJdS7Cs7c8AOJfPstMtLhFLeOxYRZNj TZFE/SmlGjKNzUlVaPK5GUpA9iPgLzc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744167039; a=rsa-sha256; cv=none; b=7B7MtXUwuTb7zLTwKaANDUJLOPVstNupCTM4gVobDfz1nVAqraYZZrX3sV+PrA5Q/cuQn4 hJW9N+0AF13OnimTCZHGedRbkAnmFkPs8CnTtmfM/nt0sBKd2K2tvMuA47+/Rrk8exmgOv F9ilKoL5DSxx7nI1lCm9BiCrE4vPaug= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="p/05zKN0"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of sj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=sj@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 64B3A61143; Wed, 9 Apr 2025 02:50:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CA4BC4CEE5; Wed, 9 Apr 2025 02:50:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744167038; bh=1vyMQj7G0bbnlgmsq19xl83Td1ymxWFwpTojbnZNiFM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p/05zKN0Z5ms9qbA/u4dubP7wCDMrwWlKM2JCSpb4M8Gsf/hMeXkgjQFG1Jo5SEJ9 HaW07bFjALlsDI4mj3OWn6tHpmhf4quF/BiQCoTgu4CuFA0/qnenKp++viiEt2xCQK bh5qLg4xVmQ1ZoIFJsCl1jhcbUOcgEAAO7EcHtwv8HwfLZuDkjF2M/VCmZUbiE6C2o l393zMAZIhnPqi/lGOAx8e+8HFmClUN/FUbeFewPlL/LRvR+TRTz2WBZhee6wAF97I fZlJR1q1WikcO13H7E3kxXNZoyQ8iMqLihBV44Cf0cY0BHYMQK4njrXKV7nWtEc5IE 22qxyyhyhMXxA== From: SeongJae Park To: Ze Zuo 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: Tue, 8 Apr 2025 19:50:36 -0700 Message-Id: <20250409025036.70633-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250408075553.959388-1-zuoze1@huawei.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 66AFD40007 X-Stat-Signature: rksoy1ixcbswrp9d6yqy45rd1fcpbrj6 X-Rspam-User: X-HE-Tag: 1744167039-639921 X-HE-Meta: U2FsdGVkX19soqw1GyMiTj2S7kwicwWUioxZgNI6hMR97sm3R3eipm4x1bGZ6LOVlv4eY/tFwmQostlEXZBuPWMhfJLd3pOpiERNfNp2ahcEA2aAJmXwSvDW37BxjnIguPK+uiPvtXQEbxKGiMCQyzxSBPd8qRe06uxI9HywxDr8nO379+NOV7coLgMi1fT4geqmLgt0+nf4cV1rK05FHjVDcStIDPjrjwz2o1boRbMI3kEa8M61mWywrGJl8A0UPtlM+FbwlVv018wPecsou1GzOKoS4QM2UYSmQMNQzXylq/AAJVoCSwe+9tJ0IhB+b3BnIF0nONFYQwHDeqzy997IaD1mP/1V1yNj2cWQ3F34ienHit5jiIui4Q7OvZfg+wMCQslbclcCheXNFXnww8tcZSex/z1C6reCpdallSdgO013kv+EIEAbwsHfpR4+NVMExTg9WiV7qlgNeEH46pblAxGDMZK0xPZSOpK4HQ7lwOrveI+2wAo/9rmQUd2njVNwEovkl+zt43TgtvfC629Plv/J0Ut+2g3+vAkR4houaYR5Ps6ioLjOllRu5B89tcx/2y/51hPiFZAsi7yO90C0x/oxHx5sGqYt2IGzuVq3h+4DP/0Ad4F+MMyCiMHxtO2iDGkUoQH8qj1dFgzxAB6Flz70JqzV7ERqQN87Lc9cK9gD/g1d1UwUrvAjkKEVImyvsPLXqPQDjj0qfkBTom9aUjGj97AKqVG3kCUWg+4kMXVzGbjUfassnxBBGI5F/w47YyjVMh1MAYAgjOcVmvwMfYCnTa6kHKuSNRF2vGIIJBWcXqJfuOWAjJ8p/dwR9KQCHYi7cls/moDDW50Y55ttsPuSfZMKcwfq/rrVdxdTkDZTo/0+Qp3hIjbK2AH2mgOw7kbF3vIh5NGR75z4To0LJ4VbTbAo5k7+k1yf0GT5efaVm/zyPRlNPzIrqUuhMYKFXtJhtEvO1S8E/Rc 0Bw8IGDp Iukyrf0vBQEwP8CffKna7eYuVuMVJM74/ZVdRSl9Q8yKUbUPM4W2SPOWStV28MjQ6nMWOeUhGZVeLBVIp3ronfZfSgnCycopUjE3SiAT3PyYDPeTNPfGIe+QZGgCeUN/5cyNmIFsi0Fa2iekaGQZWTt1H18jh1zgtQ7wZ83y2tpidupVndsFG9fN+mhJHh0vwOmxJWygjwJsfSMk4lcGvzkD0Sa1KiqP/ptaMfU58d/1+Ss4= 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 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! > > 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? Thanks, SJ [...]