From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 2B3B723D283 for ; Mon, 10 Aug 2026 04:17:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786335428; cv=none; b=QVpq/WvkFu0Yp/gr6r1vNr9EfLJSw/BcVaCsjxCtuBffg/tWtRJn1ro9bsZnUxj+ToBn6HvgAq7OIflfSJXI9lUDZE5Kjq/pOAW1vQ91hgB69Q98m3ByokGCKbv6IRc0vx6i5f9hx1arvtWHRPS+OFbmpyhjE5mpMK56xPj9SM8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786335428; c=relaxed/simple; bh=qhF8UQ7JmYPYWVc+FHOpm5WX+LmfHj5ISLMUymd4KMI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GP493xlguzHX11TBsDWbL6TXuIdUgLz/FgBj4JejkxreGIZRh9B/N86SEd3+wKiMk3hEJawKTzTV3W8X+W9bmDzMhVik8UopVM9JZ6HpgYYJFbzLDgrhsPztxaMoiQmpbsLrO/ERuVYccUi4lK1qSgdMaIr/y38vFRWrGl/m1tA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=PLcraFEx; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="PLcraFEx" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=naUdZNScz3LOq4YnQ44LOQFyZHRAesdbsC/IKemOnes=; b=PLcraFExOHMYf2FLbqrwCTpzB1 /pqJufm3oJKLtzYWsuGHlU4uUArpOxxklvNJ97mlPxC23C6eDfihJAK1mhKEDLQ/FClmxQOgpv9nT 0cH/lcHcuWpHKGtyka5HCQbLepgO+ZjxgekcDopjgURHFtcWUUjnQ7FEaswB03M+pTTxYL2sQ3Aps /YPMnIprhbzQS5sBC0MSwLIi90RdjSndX0HzP0c+bFUyTK61bhwB9JlF5s+KA7dT/gpE2QEueD00Q p3CSunn1ToZau9PaQKesDqe7QOwjG3L/81lL8SLOCy/bvuz0SNNbQvPPw/Nx5IE102J3fMfwKzVK1 6ky8kxKA==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wtHRH-0000000AG0c-3J7M; Mon, 10 Aug 2026 04:16:39 +0000 Date: Mon, 10 Aug 2026 05:16:39 +0100 From: Matthew Wilcox To: Yongting Lin Cc: Jonathan.Cameron@huawei.com, akpm@linux-foundation.org, alok.rathore@samsung.com, balbirs@nvidia.com, bharata@amd.com, byungchul@sk.com, dave.hansen@intel.com, dave@stgolabs.net, david@kernel.org, donettom@linux.ibm.com, gourry@gourry.net, joshua.hahnjy@gmail.com, kinseyho@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@techsingularity.net, mingo@redhat.com, nifan.cxl@gmail.com, peterz@infradead.org, raghavendra.kt@amd.com, riel@surriel.com, rientjes@google.com, shivankg@amd.com, sj@kernel.org, weixugc@google.com, xuezhengchu@huawei.com, yiannis@zptcorp.com, ying.huang@linux.alibaba.com, yuanchu@google.com, ziy@nvidia.com Subject: Re: [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure Message-ID: References: <20260810033814.83951-1-linyongting@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260810033814.83951-1-linyongting@bytedance.com> On Mon, Aug 10, 2026 at 11:38:14AM +0800, Yongting Lin wrote: > On Tue, Jul 28, 2026 at 07:24:46PM +0100, Matthew Wilcox wrote: > > I don't think we should do this. I don't think it's a use-case that > > customers actually want; I think it's something CPU vendors think their > > customers want. I've said this repeatedly over the months this patchset > > has been in development. I say no. > > From our perspective, this is not merely a hypothetical use case. We > are actively developing and evaluating CXL tiered-memory systems, and > expect promoting CXL-resident pages that become hot back to DRAM to be > a practical requirement. But what *is* your use case? Truly hot data ends up in L1/L2/L3 no matter whether it came across the ridiculously high latency CXL link or from regular DRAM. So we're talking about "warm" data that's presumably measured in gigabytes (since current server CPUs have about half a gigabyte of LLC) I see the basis for saying "this task is low priority, it gets its memory allocated on CXL" and "this task is high priority, it gets its memory allocated on DRAM". I don't see the use case where we're trying to figure out that region A of this task is sufficiently warmer than region B, and so we want to demote region B back to CXL and promote region A back to DRAM. I particularly don't see a case for trying to do it on single-page granularity. There's just too much damn information to track. Maybe at a 2MB or 1GB boundary, but not per page.