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 E758A48CD41 for ; Wed, 29 Jul 2026 13:54:24 +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=1785333275; cv=none; b=t1eSsM16L0uvalQbGeEzivBned+wuC8yCBGd7UOrZV2Pyn8MXKdGpUyaJ2YxWRe/X++9g4jokpN1Mkz6aSJtqAooIxjHJzSCGqztsDPWU3qTty0fsTBVRSea7ECBjSQsF0kWFItHgP8KFQg+Ikk4cs4Nwq8R4hyDu1qzsD5mgkg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785333275; c=relaxed/simple; bh=Ocz5H9SmdNY6TV3TgAzLCKP2o+41PG3g0Crg/hzS5dg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZqLu8QmnBI0Y6gr8LDO8xkQCBT9dR6P6dAdk6/xOjMqtZUGqSU/0VaAH2ZrBMUJhQ1W9QFlHkFNVXys7wBoVkQhBLXKKblp3fCsGjO/0+Q8UjBTr4XW+Ig/hisgBAQvJK7g1ym3b/IzqFc8I2J0L2nlwfph8MGdoP0er6bh8r4E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FD0JedG9; 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="FD0JedG9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 709991F000E9; Wed, 29 Jul 2026 13:54:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785333262; bh=V7bhTggPy1yNLnQ4gXjtK4joscfsFAiI9ZCSDdA1JTY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=FD0JedG9h2X/yjPsQoeyUbAPJnmI9XcssRBAAZlmpVvEiokkGlwFs7ckacNGUQWkQ d8lhMunpzVbFyRcOWMDKnIBbzgp2cqGXhY4+BpQhQ9I3diccsmyj+2Av2rF3WjhBN9 EflLb+3JvwQ6usS4AA8O5pqWvDGtQtMSt7AN7iemM3+vHQby3jqO2MPUP1kvQJUxB4 MaGaEk/oXd83f7toy2Gi+fC43/gu05DOqsovCrXPf1CAYaw5ifKbe2ItJ1Gb1Uj6Jc kALpBJIcCS0EO+2iZxpahH9DLcuV/d3XyxjflN3Pg8Lh5YXVkp80bt/dOEaDwYCkTU GlrVr9j+etzbQ== From: SJ Park To: Bharata B Rao Cc: SJ Park , 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: Wed, 29 Jul 2026 06:54:18 -0700 Message-ID: <20260729135419.87239-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <125de6c4-2fc7-4202-9199-347effe63112@amd.com> 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 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. 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 [...]