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 70F37C36000 for ; Fri, 21 Mar 2025 17:42:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAFF5280003; Fri, 21 Mar 2025 13:42:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6005280002; Fri, 21 Mar 2025 13:42:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2866280003; Fri, 21 Mar 2025 13:42:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A45C7280002 for ; Fri, 21 Mar 2025 13:42:40 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 59F4DC0465 for ; Fri, 21 Mar 2025 17:42:42 +0000 (UTC) X-FDA: 83246278164.25.8C575F9 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf03.hostedemail.com (Postfix) with ESMTP id D18B920011 for ; Fri, 21 Mar 2025 17:42:38 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.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=1742578959; 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=9G1iP2Ttlik4P5iqoFJehuslFxMeK4DUaoKPjQTOgsw=; b=nEI1UlK2Orty2YJDBNRm3Sv6yU7PsRDwYmHr94oIfnh+AoYugjDoMRqLD86DLRgtU7Sjqu hIKPu6NqnSKSdoaa1iswPS5gPjNeQ+tUeBoW4MBNfP7yhhzZVNYjhgCrNxxWS9Beab7FJL VZSSvnS+ooexadYeKfYPAiCfwS/gC/4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742578959; a=rsa-sha256; cv=none; b=ha1jH29mc5v7MPh9xMpHCOae+HworXIEc+JWyJ/D6Dda81YbduSTVsARkqCpbaIdd1w7DM b1l1bcyePri5TI9R3DIV1pSi4TBbv9qQtEq7ylqlUMl+Z/m+/Z7YjCz4fADaNPLlX+aYBU KbNZQDh8wVynRXK9R3E5fdSR/O8o2yI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.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 Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4ZK8pG1h8Rz6K91Z; Sat, 22 Mar 2025 01:39:34 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 8A96C140142; Sat, 22 Mar 2025 01:42:35 +0800 (CST) Received: from localhost (10.203.177.66) 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, 21 Mar 2025 18:42:33 +0100 Date: Fri, 21 Mar 2025 17:42:32 +0000 From: Jonathan Cameron To: Raghavendra K T CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH V1 09/13] mm: Add heuristic to calculate target node Message-ID: <20250321174232.000047fa@huawei.com> In-Reply-To: <20250319193028.29514-10-raghavendra.kt@amd.com> References: <20250319193028.29514-1-raghavendra.kt@amd.com> <20250319193028.29514-10-raghavendra.kt@amd.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.203.177.66] X-ClientProxiedBy: lhrpeml500005.china.huawei.com (7.191.163.240) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D18B920011 X-Stat-Signature: puefs4xmipsr5ji6apjnjmreh48om86i X-HE-Tag: 1742578958-61765 X-HE-Meta: U2FsdGVkX1+WdakAk0AbaHD31sH6mamrTL/x4fPFDtjBEhZL0UmyZQSYO1WhV4nnc7G3JJOOom0wJ7sVVh5gN7SxO4M1vZM4Y505o2EqAETJNE398YLRXQWU+dfpmnbIQde52HD0X8ASuAq+iI2y6v1P+XsoODxPmQ/SvlZNuADeHuNF4pO1sGKZ46amCgC8Oini59onXFeY4O/ylt9diOfOGPN4CAJxcCNSBEelam1KneTyWD/ZwNgdr/7y149kR70srVPOB0OKLF7YlSywonYq0MHOFy6cvbg+/Ev889q+X//FiBZ9V+cEZpWcXSFvm19z2gEuqInL/2KEq8W6lvqi6z43JZrOhOWqK/QOIDkbfpotwwo6bxq8WlZqcsDQIMdT8XzVk7BTHUjbvDz8xLE9DUkUg+kX1i/+OT2QONiX9d8m3UGH+HIUvhcA2KfYvKzPxyxCUC478Eg2TMY8oCXPN5XOaqYwbc6OrVJU5USRug0XkN78igUQshnyOOc0BXBg3rJsvQZ/y4okw0yuSibtefdSJwWOv6CVJSALPE1iSqBSHhq1kr+Pt1OhylI+yCJhD/D40RdbqV8OJcZR0BjikxavjVJFPsP+oz+sp4/Vcgl863BK/NIjvUBc7EDHC+ynmI5rXY9qH8mwIrVF12wykcddg+DCj5HnQxCWWtHRvbO4LYZKl4wFqJ2Eii5xtgInRC4bUbHc6Bpa8QoKqdeY/EOS2Zf2E725DDRYWKVt5rHq9x2tBn6odbNvtuvZB7/E7skPRWcaamRJLBL17uc8yAkV6BHEoxByfhssgKsqyo6wY0pCoRqAWT5Jzr72YRaTNaaJTjQ7TZRJcWihtlOMYatfODGsPIq5Onvv+7M3/tApxzHszibuVtLV+ltCQ0G2kfMKIX+dBeDpNpBLas7YcOqlp6SgNWGTW499SGR1pt6ezWJLDcXJJhY6UIX4/TlA2PfmjqpCYL1v4gT KMgzoedg xlH31JgMyCIOdfUJzJCBn8y7/SVcbJm9f4LXHSMo07dT0/tFzLTSvftLa+mH7/Up2ycVGccPiMO0Fm6WXjvAgZ7KVyUIMo8Tuq95cXh0AR8F+Iz3jJHdHaXlEW7mqyTf3M7rhkU42cU1gmmehUxwxq9Grq1yKCz3LSVFYfYbPZKCEakSVz7a8AKPAD1waDlZdRpbAGVBA5k5y8oFor6lws1w9TqStCFuSuTEsRFvS/sIURsGUYv5hy4ofc8mUc2fUmOZX+hq34UuTKG0= 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 Wed, 19 Mar 2025 19:30:24 +0000 Raghavendra K T wrote: > One of the key challenges in PTE A bit based scanning is to find right > target node to promote to. I have the same problem with the CXL hotpage monitor so very keen to see solutions to this (though this particular one doesn't work for me unless A bit scanning is happening as well). > > Here is a simple heuristic based approach: > While scanning pages of any mm we also scan toptier pages that belong > to that mm. We get an insight on the distribution of pages that potentially > belonging to particular toptier node and also its recent access. > > Current logic walks all the toptier node, and picks the one with highest > accesses. Maybe talk through why this heuristic works? What is the intuition behind it? I can see that on basis of first touch allocation, we should get a reasonable number of pages in the node where that CPU doing initialization is. Is this relying on some other mechanism to ensure that the pages being touched are local to the CPUs touching them? Thanks, Jonathan > > Signed-off-by: Raghavendra K T > --- > PS: There are many potential idea possible here. > 1. we can do a quick sort on toptier nodes scan and access info > and maintain the list of preferred nodes/fallback nodes > in case of current target_node is getting filled up > > 2. We can also keep the history of access/scan information from last > scan used its decayed value to get a stable view etc etc. >