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 87113C02193 for ; Tue, 4 Feb 2025 23:06:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 042AC28000B; Tue, 4 Feb 2025 18:06:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F0DCE280001; Tue, 4 Feb 2025 18:06:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB18B28000B; Tue, 4 Feb 2025 18:06:41 -0500 (EST) 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 BCC99280001 for ; Tue, 4 Feb 2025 18:06:41 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6D7D6802EB for ; Tue, 4 Feb 2025 23:06:41 +0000 (UTC) X-FDA: 83083798602.09.D3C82C6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id BF8011C0010 for ; Tue, 4 Feb 2025 23:06:39 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="tu/Cossp"; spf=pass (imf18.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738710399; 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=9TEuexuMHqJSB8hd9AJe+Bp3yQJs1hnLZxUqVN8YE2M=; b=NvouKGJl0bLrrXbbStD22XSWoHgNgt5+4TmoiWKo0kjglVKh9YRF4TUETnf8EUUWhvzQr4 BYfJdcYTsPeee3OwfOsIuIyliQRdViU07aqM0mVh/XDvhXERoN7Ja+Fezv7lmiNcb/QRzs ec7dYxj6l4RxpfpBGKnj2CLdo+yhJEk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738710399; a=rsa-sha256; cv=none; b=Ex0OT4zkI7I28FHRnlK0IJWlwtjJOWpovFxxwWGOKAbtaKXXcvj3coBSRYNOo6fEeGazYD 2a1WgVrnYsyvOcZf2K4GVOviI/HtLdEeNekL4uBy5ol2iAm+k2q5yIL96Vapht8xYjaywG ef1ALDlKVDmtl1lNTddNmUMaTfnszqE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="tu/Cossp"; spf=pass (imf18.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EA4975C5C11; Tue, 4 Feb 2025 23:05:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41756C4CEDF; Tue, 4 Feb 2025 23:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738710398; bh=5BkAsVQ0nPHirdPibg830SVNIrWkbzxA3OWt0ISmOCM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tu/CosspCqzpdTu6dpjhSzl3bJoX1nDhsLiHrXBpC2HIpqdWacRi532OMeKCu8Xeq f3vZnpS5nNE7rf0d6fIkIK0QU2bwQ+Kcq0b6oy/vBQSYkLqT4QVRTGRuJJs1HOkAfx +ER246v+wz5iaxF0krVEnV8/tpmKmIcldz/liDwkgqWfiLPBH/ytYh8CQvFiWJPt4d Nz937/jkg3nHle6Eg/rvjLs+B8y5KE91Jr85NYNxgHUBW9fRHOpZ20MjRWAyWCQ4Tk M0Mjl/MCx8maA5ubb1VhnSTUKKmifGu57xUSbSn27SJjRpPhH8P9/dFVIVJFFptwtH 6UYZlNaB57MrQ== From: SeongJae Park To: Usama Arif Cc: SeongJae Park , akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, hannes@cmpxchg.org, david@redhat.com, kernel-team@meta.com Subject: Re: [PATCH v4 2/6] mm/damon/paddr: use damon_get_folio_in_region to obtain folio Date: Tue, 4 Feb 2025 15:06:34 -0800 Message-Id: <20250204230634.2577-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250203225604.44742-3-usamaarif642@gmail.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: BF8011C0010 X-Stat-Signature: z1774e6rb1mnminxpk9jtu5oifkdi1s8 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1738710399-722742 X-HE-Meta: U2FsdGVkX18L02KgmxW83tzqruhK3uMUHunJv03rK9F0LjZ0o8dzc/s2YjxIXcdD1r+HJtijd47qiJcJK+EEfla08XBSO+2W8K3Mv7BrlcSRwfIW0ckVIlBDaEMsvcZLv9uh4Q7Ih4UI21qVEyWANTovwht3bnHGHRYEeGxlViZmu2Ea7WYaoXV32EQ1EtW7hM0P8jTmJ9DLRCccXSkUv3A40LGfvOsv51DCP3m8HUCOCi/Ok4q6lvdLoM0jnhHEEZgmfKSMzc9iMxrhbWnzIPd+7KUiLT8Td1W1SbZ4Ixwq5r3vP9DnHl4+0EJT7RNTAkg+h8debS7MAGXcqj7ExGvJOW09ovonUwcD9a7HSYdRoFxoeS2B9tOZVPsPJWD1XPNWMQoG6PdZPnJIEpe+Q73Cot9P0c0lWk5Bq+GsR1uBgZ7sMz+1HklIjfOC+KGY5rz1rsy40y6N3NWRKkb8SUBZhKy2/cIU1LrsZQdOJMLBCeAmnw0AF+ycifRsE+JlVxKfrh3RsTre6c0jhZiXiCDELY7b3GGe8lWeQeph9mqk76sxMJ8iBcKlMBH6q0uoS0ZBk3rc98sv3lh+Jj+8/7OodvBqtAhpOxqhZGcOeXVkml8CVzAO7wzXyjXV7YxlHAdVOHPTc/dn4cvcAQAvInqw/BWMbcDiKXs5etaL8fyMhZDrGRg/dtchAxsZFfgStHFjKgFZc/bfjRNO6hAfPzoHUwpE38d9xkJc7GdqxpR6P7RdQKRsD6TH9yQfSr8Ha/11L7CRHcNVGEv92MT7/YVeZZcKclv0JwjrJc59aGdsdQedOyfnKs808+N9eK5VED3FKr1neeULNUCNLWWSnZyLmUL2iszYMWSY6b2oqHGhVv/Si6UsNslXkQq1NzuB5IxbxRL+dWR7fhiTUQ1tH5DbcNmoh0Apnryu5HOXcqEz2tMm5pdowhVBb60o35qeAmvoR/l4RLK43xL6dJ9 p12+3kU8 /vdcMI6qkJGyxWe60birfH8JPHzEJFFgoAW2rPze60gEEM6eMmfm5cwC7EgsR+sJgoNlvxi7dGh0aDsyCA6TGbiWX1sw/jtYkx15qNbSE1AdIZP1lTiYGBoLvG7cvMWasrXrbq9WS+qPFoCeuPQ6CgWjOCLqeino2sG8D/Y7W7jNslkzON2TjjkGYiZZGCllYj/qyx+NU6MA5ZltLd+E6OViz/TqbjrkyEXy1GslldPyuDSUYztU8+IXSrRemayMoPuxHsVDh7LkTSnvAt1ruEg10ow== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000093, 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 Mon, 3 Feb 2025 22:55:29 +0000 Usama Arif wrote: > This is introduced for larger folios. If a large folio has subpages > present in multiple regions, it will be considered multiple times. > This can be when checking access I think this behavior makes sense. If a 2 MiB address range is known to be accessed or not, treating DAMON regions in the address range as all accessed or not aligns with the DAMON's region definition and makes sense in general, to me. Note that DAMON's adaptive regions adjustment mechanism will make the DAMON regions in a large folio to be merged in near future. > or applying DAMOS schemes. For e.g. > in pa_stat, folios split across N regions will be counted N times, > giving inaccurate results. Nice catch! I agree this could be a problem. > Hence, only consider a page for access check/DAMOS scheme only if the head > page is part of that region as well. For access checking, this seems wrong to me. This change will unnecessarily mark some DAMON regions as not accessed. Even for DAMOS, this seems not very optimum. 1. DAMOS will unnecessarily repeat PAGE_SIZE skippings on second and later DAMON regions of a same large folio. 2. If only a small part of the large folio belongs to the first DAMON region, and the DAMON region is not eligible to the scheme, while the second region is, the scheme action will not applied to the second region. Also, I think this problem can happen on vaddr case. Hence, making the change on core layer makes sense to me. That is, let damon_ops->apply_scheme() inform the caller (damos_apply_scheme()) how much bytes of the next region should be ignored at applying the action. Due to the complicated implementation of DAMOS core logic, this might be not very simple. I think the additional complexity might outweigh the benefit for following reasons. First, adaptive regions adjustment mechanism will make DAMON regions in same large folios to be merged soon. So the problem will be not significant in common case. Second, any threads could collapse any parts of memory into large folios while DAMOS is traversing DAMON regions. So this problem cannot perfectly be solved unless we make DAMOS' DAMON regions traversal exclusive with any large folios collapsing. Which would add more complexity. And given DAMON's best-effort nature, keeping the issue until we get a simple and effective solution is ok to me, unless a real significant issue from this is confirmed. Usama, what do you think? Thanks, SJ [...]