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 42865C0218F for ; Fri, 31 Jan 2025 13:09:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 66B032800ED; Fri, 31 Jan 2025 08:09:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A7812800E3; Fri, 31 Jan 2025 08:09:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AA682800ED; Fri, 31 Jan 2025 08:09:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 10A192800E3 for ; Fri, 31 Jan 2025 08:09:16 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 68371140B4D for ; Fri, 31 Jan 2025 13:09:15 +0000 (UTC) X-FDA: 83067777870.22.934B963 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf29.hostedemail.com (Postfix) with ESMTP id 9A6C0120007 for ; Fri, 31 Jan 2025 13:09:12 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738328953; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k8ALPzjRTyNsVnBFIyE1eebzBSeQLMmJYklZPTTVyt8=; b=erLFc+BKk1/tPScmKi0j6J3uvn2WC0f+AVkVD98wjDfsRTAEIp4njeHg74z98IgsCcTFEM y5lNhIIbe4ZknQAzv3YxZibYRr37OgFBgMn2f1eQJjO7pwoNgAZcIwN9CYjp2cR8aHqR4N vjvSfegFpKqUkdLLgjOJH6i5BcxTndk= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738328953; a=rsa-sha256; cv=none; b=ANmE1FEnYfZGQWWvUb4X9rCZVztI2UxtkYr3fXVmFmkt3ovuCEiNFfCZ8tl0qM7UcM2vAR ALZ+6uakZ/6KF76FInVKShyccJDpH/adTq/rcHihnOe9+r1dPpM+kvAoe/DfDsonFGJEU4 Hsxs0pMk0zu8yD73U1szmuXqEYa3FM8= Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ykx4L0QbVz6M4Pp; Fri, 31 Jan 2025 21:06:58 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 68CE6140517; Fri, 31 Jan 2025 21:09:06 +0800 (CST) Received: from localhost (10.195.244.178) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 31 Jan 2025 14:09:03 +0100 Date: Fri, 31 Jan 2025 13:09:01 +0000 From: Jonathan Cameron To: Raghavendra K T CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [LSF/MM/BPF TOPIC] Unifying sources of page temperature information - what info is actually wanted? Message-ID: <20250131130901.00000dd1@huawei.com> In-Reply-To: <20250131122803.000031aa@huawei.com> References: <20250123105721.424117-1-raghavendra.kt@amd.com> <20250131122803.000031aa@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.195.244.178] X-ClientProxiedBy: lhrpeml500009.china.huawei.com (7.191.174.84) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9A6C0120007 X-Stat-Signature: 8rh6nr1km9mbgxp1yo3cozcozkqjzafi X-Rspam-User: X-HE-Tag: 1738328952-187833 X-HE-Meta: U2FsdGVkX1+YSMc/OhLOTxVqmoG4Ui1qs5oBHUZbH7QGBfEuJ8so69Xv8YvCj1Hk77URl4Bw8W41+X2l62nResT4VEXHDPX9n2HHdEGmIDLZBHM1RIX1OTlGpzCwAFvkA9OHO1YeUAa95ef585u3FxEphagXRn4lVWn7y2sJDiSBSMLE0r+L8bYx7gQAveHd+5Nx7McXjvFqfYXSQERfeMqrPwonYbXlJDuNmF3AbcTkk4YjbiE13ZBGBvEJPfqsxKoF87myyDpSSzALeBJyhwxRgPdONMNeVE++WTZaUUWAQrAWe5YAVJ7bvhPwb5Cib4jQ2uj3HIRNl7T4u5mOWm+Y43hZYcAIcG13Q2hDMDpiXYK2di3RwZ90JZ0cAnEcZndoMUjrj5H4lu1Y7XNXAwUBq0kOadx89/vOYopfv0WnvHemRiMBYrs3dU+I+GcuR5S2NQw7d1+EsMSGRBMTQ9+oTKaVQifHqMOhMM0kyVo0QjC4s2LHq9x2G88WqK2/tkB8mJtADKgP3T/Joki/l4T5ohig2ATJKE0WI5r6vhYOdwRGPqdHpmqj6X2PjEekEpOy6sOh4c1VDB4064RQzMVi3vZXcg0QleLLTmlir31FVm9DTmtm0GZ5D28FrIEjpDKu7MP/VbTtymM1/igL7opaGWIQ9xecV3/t3WImPoD73VTZc4n4rdjNlAwb8wuDjFBttdxFB0eXolPYxLxBPRfNX2Ar9QFVzx/j10U3W76611+Tj+T/QvE+C1VpJuw3g4cCCtD5t7YFX1PDP8qsU7zzj2ZHKDYMcBLD4LB9ST+IZCX6ptoSRpGS18NiujSvdEIUQg3i/6TUWMV5Q3t/RE5KZ6vcw9Vy9DjAJxLiDQ/d1uzwsw6GXFGT/cAz4GbwVbOwbWj/p7D86W4iCqqmdAbKV7e/i0wpXSfALZUQS+TrvT44j5lbDH31B/PYsdRGrafptfGpEiQ51oCb4QO ANKTRJEm sxJ1u5uGvqKqvG0wHbe1lSC4uaaTgNXmHV2r20V+ZKr2vxLtiDA868+yRWJEgEDphQFdaP2fa6/QME3Yk8xdd+t9A7ZdEAzLXymDBXUiJkN9ixyX+AI/M0wDa8DvdjvTnqgDKe7YX/gMRSNwhTMqzUjYGFKA2v6/AUtHi5ob5Z2lLlPQp0NMFuPRZe6oKuB1waonhrh0ay965/HrMnJg9f4XkmOl+KoM4Ml/W5CK0DBxlvMBlmv9PxXn0Ond82oPhRKAv0ZV6zwdm9ChZmlZ5QXFGmtDqJ3C7mckxwWcmpc2SWpOhAo4cboIihbn11CXgCK4W X-Bogosity: Ham, tests=bogofilter, spamicity=0.075267, 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 Fri, 31 Jan 2025 12:28:03 +0000 Jonathan Cameron wrote: > > Here is the list of potential discussion points: > ... > > > 2. Possibility of maintaining single source of truth for page hotness that would > > maintain hot page information from multiple sources and let other sub-systems > > use that info. > Hi, > > I was thinking of proposing a separate topic on a single source of hotness, > but this question covers it so I'll add some thoughts here instead. > I think we are very early, but sharing some experience and thoughts in a > session may be useful. Thinking more on this over lunch, I think it is worth calling this out as a potential session topic in it's own right rather than trying to find time within other sessions. Hence the title change. I think a session would start with a brief listing of the temperature sources we have and those on the horizon to motivate what we are unifying, then discussion to focus on need for such a unification + requirements (maybe with a straw man). > > What do the other subsystems that want to use a single source of page hotness > want to be able to find out? (subject to filters like memory range, process etc) > > A) How hot is page X? > - Is this useful, or too much data? What would use it? > * Application optimization maybe. Very handy for developing algorithms > to do the rest of the options here as an Oracle! > - Provides both the cold and hot end of the scale, but maybe measurement > techniques vary and can not be easily combined. Hard in general to combine > multiple sources of truth if aiming for an absolute number. > > B) Which pages are super hot? > - Probably these that make the most difference if they are in a slower memory tier. > > C) Some pages are hot enough to consider moving? > - This may be good enough to get the key data into the fast memory over time. > - Can combine sources of info as being able to compare precise numbers doesn't matter. > > D) Which pages are fairly cold? > - Likewise maybe good enough over time. > > E) Which pages are very cold? > - Ideal case for tiering. Swap these with the super hot ones. > - Maybe extra signal for swap / zswap etc > > F) Did these hot pages remain hot (and same for cold) > - This is needed to know when to back off doing things as we have unstable > hotness (two phase applications are a pain for this), sampling a few > pages may be fine. > > Messy corners: > > Temporal aspects. > - If only providing lists of hottest / coldest in last second, very hard > to find those that are of a stable temperature. We end up moving > very hot data (which is disruptive) and it doesn't stay hot. > - Can reduce that affect by long sampling windows on some measurement approaches > (on hardware trackers that can trash accuracy due to resource exhaustion > and other subtle effects). > - bistable / phase based applications are a pain but perhaps up to higher > levels to back off. > > My main interest is migrating in tiered systems but good to look at what > else would use a common layer. > > Mostly I want to know something that is useful to move, and assume convergence > over the long term with the best things to move so to me the ideal layer has > following interface (strawman so shoot holes in it!): > > 1) Give me up to X hotish pages from a slow tier (greater than a specific measure > of temperature) > 2) Give me X coldish pages a faster tier. > 3) I expect to ask again in X seconds so please have some info ready for me! > 4) (a path to get an idea of 'unhelpful moves' from earlier iterations - this > is bleeding the tiering application into a shared interface though). > > If we have multiple subsystems using the data we will need to resolve their > conflicting demands to generate good enough data with appropriate overhead. > > I'd also like a virtualized solution for case of hardware PA trackers (what > I have with CXL Hotness Monitoring Units) and classic memory pool / stranding > avoidance case where the VM is the right entity to make migration decisions. > Making that interface convey what the kernel is going to use would be an > efficient option. I'd like to hide how the sausage was made from the VM. > > Jonathan >