From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F004F27A92D for ; Tue, 4 Aug 2026 01:24:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785806646; cv=none; b=glh3Z3oBrtdmpS5lXniv/ift54PTlZe/R4tA43PI1sKbj0M/OmevuWK8VKJ60L6XzJZ3IeqwiP6u+TOmlpgj4g6sx9qoKhx22h1ZGTY6X8BebSdpxPSV9am7TeEYtYpqPY1Tp9CB1DSS+Hli76VlDoGeaN19bhQuzkubK1MtzZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785806646; c=relaxed/simple; bh=b0/u8xNNYyR9PB+Wu6uYWYIox0m7i4ueFoiPl6rwTK0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BU+2z+at8lhXZip0a5Reg31f1G40YIuzOP7F9jKaKD5Hm33dzfYlJp1aP9mv4PwCcU5mEF4Nv/mwCVwYPzSLoybgK2wc35eAFR+DPvrW1TqARC0mJAWcYI4GRJL4jwcmiKI1Op5UroFlMDuVhPsdS+ycNvARg35RK8j+UiFYGGg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bVE+bVkr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bVE+bVkr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3A9D1F000E9; Tue, 4 Aug 2026 01:24:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785806644; bh=a6Nq6xJoAXoC/LygU8ixMhFIyHGQ4zkq0yWeBWhUdOI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=bVE+bVkr6+yjsaGNwMdTqU2p1gzA7cDkqkM6wfF4w66P8K0slCQMsEtm91ZH+RmfL 57eWLd/6h80PfSmERaktaO56Rbuctz7DsPi/8cidwGA0pu2LU1ko19AfPsZLjgFd8+ XW8RH9ZLIYRZj8WIMogWZ1ViuwANbiRAUfkn5YUsqNIiUQSG8Y2BTW3sJnkvQoWZw4 HAS07NjfcEFv+iziTL4UejfbsIRVpEQ99m5v3FiUQRD8uEyBytTKbPqmiGsFTD9WFZ rtJfwGpS4PC7njpl9DeT9JSjwQgi2sYS1aD1fhGoypPRDVAKFqt2hab353uOuFFNcg mv955kVKl4sPw== From: SJ Park To: SJ Park Cc: Bharata B Rao , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Jonathan.Cameron@huawei.com, dave.hansen@intel.com, gourry@gourry.net, mgorman@techsingularity.net, mingo@redhat.com, peterz@infradead.org, raghavendra.kt@amd.com, riel@surriel.com, rientjes@google.com, weixugc@google.com, willy@infradead.org, ying.huang@linux.alibaba.com, ziy@nvidia.com, dave@stgolabs.net, nifan.cxl@gmail.com, xuezhengchu@huawei.com, yiannis@zptcorp.com, david@kernel.org, byungchul@sk.com, kinseyho@google.com, joshua.hahnjy@gmail.com, yuanchu@google.com, balbirs@nvidia.com, alok.rathore@samsung.com, shivankg@amd.com, donettom@linux.ibm.com Subject: Re: [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure Date: Mon, 3 Aug 2026 18:23:55 -0700 Message-ID: <20260804012356.88861-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260729135419.87239-1-sj@kernel.org> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 29 Jul 2026 06:54:18 -0700 SJ Park wrote: > On Wed, 29 Jul 2026 15:05:10 +0530 Bharata B Rao wrote: > > > On 28-Jul-26 11:44 PM, Andrew Morton wrote: > > > On Tue, 28 Jul 2026 11:13:48 +0530 Bharata B Rao wrote: > > > > > >> This patchset introduces pghot, a subsystem for hot page tracking and > > >> promotion. > > > > > > Can DAMON be used to do this sort of thing adequately? > > > > That really depends on the goal I believe, let me expand... > > Thank you Bharata, this clearly explains me your view. I find a few little > gaps between yours and mine, though. Let me clarify below. > > > > > DAMON can indeed migrate hot pages today via DAMOS_MIGRATE_HOT, and > > IIUC it can even do promotion and demotion together that auto-tunes > > to a target node utilization. So for someone who wants to write a > > per-workload, per-process tiering policy from user space, DAMON is a > > good fit and I don't think pghot competes with it there. > > > > But the intent behind pghot isn't really to be another migration > > policy. It is to build a common in-kernel infrastructure that can act > > as a single promotion subsystem, fed by multiple sources, with the > > promotion engine and its heuristics (rate limiting, dynamic threshold) > > living in one place rather than in the scheduler. Hint faults are just > > the first source. The IBS Memory Profiler, which gives access > > information directly from the hardware, is the other one. CXL HMU can be > > another potential source. Hence the design centers on an exact, per-PFN > > record that any of these sources can update, rather than on sampling. > > > > The per-page, source-driven model is where the two differ the most. > > DAMON estimates hotness by sampling one page per region per interval, > > which is low overhead and self-contained, but it may miss a hot page > > inside a region. > > DAMON can do [1] fixed granularity monitoring, down to page size. Of course it > increases overhead. A few people are using DAMON in this way, though, and we > are working together to optimize it. > > > pghot records every reported access at PFN granularity, > > so it does not miss, but in turn it relies on a source to report the access. > > DAMON is not designed to use only the single source. We started working [2] on > extending DAMON for multiple sources including AMD IBS. A few working > prototpyes are shared. We plan to share the first version at next LSFMMBPF. > > > > > The other practical difference is that pghot works with no user-space > > agent at all. With numa_balancing=2 the promotion just happens, and in > > fact pghot takes over the mode-2 promotion path that currently sits in > > the scheduler. DAMON, outside of its built-in modules, expects a > > controller in user space to drive it, IIUC. > > For a level of auto-tuned hot/cold pages promotion/demotion, DAMON-based memory > tiering doesn't require user-space agent, either. Only a number of simple > sysfs file writes are needed at the beginning. > > > > > So I would see DAMON and pghot as complementary rather than one replacing > > the other. > > I have no strong opinion. > > > In fact DAMON could well become one of the sources feeding > > pghot, and conversely pghot's batched, rate-limited engine could serve > > as a migration backend. One thing to add for clarification. DAMON is not only for monitoring. It also provides a general access pattern based operation engine, a.k.a DAMOS. It provides auto-tuned rate limiting (a.k.a DAMOS quota) and flexible filtering. Hence, yet another imaginable way of the collaboration is plugging things in the opposite way. pghot's multi-source access monitoring becomes additional access check primitives feeding DAMON, and DAMON serves as a migration backend with its auto-tuned rate limiting and filtering. I proposed damon_report_access() in LSFMMBPF'25, suggesting this kind of collaboration as one of possible use cases. > > Makes sense to me. If there are needs, we are open to add new DAMON APIs. > > [1] https://origin.kernel.org/doc/html/latest/mm/damon/faq.html#can-i-simply-monitor-page-granularity > [2] https://lore.kernel.org/all/20260525225208.1179-1-sj@kernel.org/ > > > Thanks, > SJ > > [...] > Thanks, SJ