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 B4198E77187 for ; Wed, 18 Dec 2024 19:23:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECCB56B007B; Wed, 18 Dec 2024 14:23:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7CBE6B0082; Wed, 18 Dec 2024 14:23:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D445A6B0083; Wed, 18 Dec 2024 14:23:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B59766B007B for ; Wed, 18 Dec 2024 14:23:53 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 64A771C7A4D for ; Wed, 18 Dec 2024 19:23:53 +0000 (UTC) X-FDA: 82909053822.12.03B642A Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf13.hostedemail.com (Postfix) with ESMTP id 76B3520015 for ; Wed, 18 Dec 2024 19:23:20 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=axoBwgSE; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.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=1734549801; a=rsa-sha256; cv=none; b=R5hDizl4gL+v9iReb6ewS2S5Y7HlqUB5mKbjgbgBhOrW8wqGD7BQxZXbf77p9wRnWjYNgs +imnlx58v7WLB13WPir/3wXaOBXPmUX610O44aNIt5/TaSNgjArVFdnV9Al285NI+zYaOG HsQ29BtoZK5l6rRSOx1sqX+GdzTTQ60= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=axoBwgSE; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.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=1734549801; 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=WDFlnGJqIhyQEEosDbA0pguNvuJ7JudBizDLrIL0Ki0=; b=R4laLa8BlEy0OQmRa4GqSE179fygJW5kEvPR5ZJy7pKCPC1UUJgsyJGpkhqscs9R9cCtzB DfjAidH1rtizesSawHRlJ+XVEWRaLwzKQBUHVAg99DMfYZ51nmJ3VEp0JZ+0HBU4ctbS50 qYw7+G46vGE8IjYjfYzyomNkki5tbK4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 350E8A40587; Wed, 18 Dec 2024 19:22:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 505DAC4CECD; Wed, 18 Dec 2024 19:23:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734549830; bh=6rKdVyJR2uDv1WEFlt1zS3QtkF9TYGoid4xQW5OEaZA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=axoBwgSEAPUUv6qOmU0wurG6KKjF316EKnbfWb2layhzbXi4U3ySVYgo83XTBfafL hovwN1BHdetm7WgVC3e3xB1diEjEmYrDIydvxbBqw+paJdsCHgB12CYQCC8A127ppg Q/kPz0msDAxQU0LTIttJvhGhU+y232a/RAAX+4TOy9R+iUSJMZK37qQ/7a/wobSc0I Wlqq7oDdQ8kYpoPQFiauW9oglchcSvkn1uiN2INi6ed+XdgDZ6YwLbir5JVI4U6IIg K3kh6sGnT04dz8PpsFvjc/hhkhEFooVYyS8moJPM3Mn9U/mFbL98l2hlHhkw16sJ8N M+F+yAe5fbQlQ== From: SeongJae Park To: David Rientjes Cc: SeongJae Park , Aneesh Kumar , David Hildenbrand , John Hubbard , Kirill Shutemov , Matthew Wilcox , Mel Gorman , "Rao, Bharata Bhasker" , Rik van Riel , RaghavendraKT , Wei Xu , Suyeon Lee , Lei Chen , "Shukla, Santosh" , "Grimm, Jon" , shy828301@gmail.com, Zi Yan , Liam Howlett , Gregory Price , linux-mm@kvack.org Subject: Re: Slow-tier Page Promotion discussion recap and open questions Date: Wed, 18 Dec 2024 11:23:47 -0800 Message-Id: <20241218192347.49227-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <6d582bb6-3ba5-1768-92f2-6025340a3cd4@google.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: u9jdyo83ojouixmriaoyzr6sr63qnh5g X-Rspam-User: X-Rspamd-Queue-Id: 76B3520015 X-Rspamd-Server: rspam08 X-HE-Tag: 1734549800-932890 X-HE-Meta: U2FsdGVkX1+D6ln0ajtwYfIsjsToB3STPRRTZ87OXQ4hbFy9koMrtdTv+vtw+9+G3Wk62SjIa07Ce8XsU6zI0zHUVuI3kbQBoSdD9MUgfCFgS6jdnNlyEannJLJlSFeC0f9fHmmrSBUG7YE3VMGoLpcXlHwBf3GO/ygd5+A+x4ZpCBh8XYTh9cyYn0Psm2mS0HzAhxJZe59hWhvi4jMCOjImKAUfqET5GUfmNPYsoa6CykFAvpwQ5Wr80kLVIhS0wlaJi9w3pdExDG8GrYeG/p0PusPNL7XkGezjaEtxGqasYhCwtxijEAk5Ao+CaQGVqultybHGpHE2UIjxMpYHyDFLgkl/2LnY+elTToG1oBhz4ZbeEIhXuboCG89L1uVQrOKszLFOlPAeRxV+nL76mzPOKMro0vP+yK4IsCygt6fpuCcZ3PkLzhie/PTkGCRPqAoTMlpVkndFJVfPxHpvTW9McPxNDfxfahtBLpKMtFekNMGG48sd/3YnMuglHy0lRduI0SuP0YQDAc/DOMLOp3BTLB9O+HV1uo/W5vvNI+eLbGYzubWezSzMxNQTBcgt33cDVkSGfyWHKmAorti7GrqkLBgFsAGXFwgrZ6ah8SCoG5FwKTJQMlt4ZaaVrfxiQhO1asSXCTEGub9qaChtc+jMStNif4A0EFAM0efuQ+pEFfsMbjjARRZkcD9mYZj1SZypikJ7OL0eNTDrY7meMWACqXR60+yG+20OHh7NBOqKhDOOpNR0jIL7lLvK4WrBI1joiQGYAipBXVivviLaM2AiFGvGBRqohqlZRV4L5NhqJ5o0sMmXGs4QUls0peysiBw6X9EgyJyUGVfTyeCBakB6utv9e7XcapoVsF4w4HCZ+wLrLkIhgXlHdzMSJ1XeebB+V5iYfop89hLkCiwL/T8fgtsLnG/g44OdZXeuX+FnyQQXmu1yYRrx/OSDNNPOEeF7UHmbMPOOAA+dY3J kuQN5AYz p6HnpSUQX3BZc+rKH1NTxfn5IJpxnCEcjUxx2TvZUvxb2UJ8zzYVKdheJorrvLI5drR00uzRYtfZuH+gbL46dn8fILyGYVLgFZ+CfkaZNhTkOw4s14Mte12Rz44dLfPK0xKNrzh1+WZny9zP0wftgn3yoEbsc9Xuq1hcuWJDXemmSLe+zTaIyGPSRhCA0vYDCFxGtR/QQggg9jWgVAqs3/J/YP6SagZLyl2yJHqIqvZOPNhzwnOYtXLuYZIg5+j2+qt577Z8HKGz0VREFL4ecjEp6wR96gjrXafaluYxX9UalXtHnOx5rDEnlhQ== 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 Tue, 17 Dec 2024 20:19:56 -0800 (PST) David Rientjes wrote: > Hi everybody, > > We had a very interactive discussion last week led by RaghavendraKT on > slow-tier page promotion intended for memory tiering platforms, thank > you! Thanks as well to everybody who attended and provided great > questions, suggestions, and feedback. > > The RFC patch series "mm: slowtier page promotion based on PTE A bit"[1] > is a proposal to allow for asynchronous page promotion based on memory > accesses as an alternative to NUMA Balancing based promotions. There was > widespread interest in this topic and the discussion surfaced multiple > use cases and requirements, very focused on CXL use cases. Thank you for keeping the series and this great summary, David :) [...] > ----->o----- > I followed up on a discussion point early in the talk about whether this > should be virtual address scanning like the current approach, walking > mm_struct's, or the alternative approach which would be physical address > scanning. > > Raghu sees this as a fully alternative approach such as what DAMON uses > that is based on rmap. The only advantage appears to be avoiding > scanning on top tier memory completely. IMHO, there could be more advantages of physical address space based appraoches. Easier handling of unmapped pages and short-lived processes, applying different access monitoring / promotion policies for differnt NUMA nodes (tiers) are some of those off the top of my head. > > ----->o----- > Wei noted there was a lot of similarities between the RFC implementation > and the MGLRU page walk functionality and whether it would make sense to > try to converge these together or make more generally useful. > > SeongJae noted that if DAMON logic were used for the scanning that we > could re-use the existing support for controlling the overhead. Just to clarify. I added this comment since there were concerns around rmap overhead for pysical address space-based monitoring approaches. [...] > My takeaways: [...] > - I think virtual memory scanning is likely the only viable approach for > this purpose and we could store state in the underlying struct page, > similar to NUMA Balancing, but that all scanning should be driven by > walking the mm_struct's to harvest the Accessed bit I don't clearly get why you think virtual memory scanning is the only viable approach. I'm curious if you have some pros/cons list about virtual vs physical address based appraoches in your mind, and willing to share. [...] > We'll be looking to incorporate this discussion in our upstream Memory > Tiering Working Group to accelerate alignment and progress on the > approach. Thank you again for your efforts on this! Thanks, SJ [...]