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 89AC2D59D67 for ; Mon, 25 Nov 2024 19:51:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71E6D6B0088; Mon, 25 Nov 2024 14:51:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CEB36B0089; Mon, 25 Nov 2024 14:51:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 596446B008C; Mon, 25 Nov 2024 14:51:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3B44B6B0088 for ; Mon, 25 Nov 2024 14:51:28 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BF76CAD5FD for ; Mon, 25 Nov 2024 19:51:27 +0000 (UTC) X-FDA: 82825661772.02.CFBDA40 Received: from out162-62-58-216.mail.qq.com (out162-62-58-216.mail.qq.com [162.62.58.216]) by imf02.hostedemail.com (Postfix) with ESMTP id 3D07A8001F for ; Mon, 25 Nov 2024 19:51:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=qq.com header.s=s201512 header.b=o1aeNU4Y; spf=pass (imf02.hostedemail.com: domain of fujunjie1@qq.com designates 162.62.58.216 as permitted sender) smtp.mailfrom=fujunjie1@qq.com; dmarc=pass (policy=quarantine) header.from=qq.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732564282; 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:dkim-signature; bh=7cKmBtGYZs9NVjBUD0MdkFIIrOhtFk6MBLGLSc+nzk0=; b=nUratSh6NTgu21/J8abd27FSgstOAd05Cpv85MyIfrLDHYSvm2QaR1KO0OW1RmXYK/gUq5 Z9aA1T0Me4AABiE60l6skIw0Wvjde+HV8PTkCNza5B6d7aEg23w/7JdgPLhpdJnBudPL1r +2ESDK7OGlcSmGdi4d1p0snaMYNOPIU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=qq.com header.s=s201512 header.b=o1aeNU4Y; spf=pass (imf02.hostedemail.com: domain of fujunjie1@qq.com designates 162.62.58.216 as permitted sender) smtp.mailfrom=fujunjie1@qq.com; dmarc=pass (policy=quarantine) header.from=qq.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732564282; a=rsa-sha256; cv=none; b=nZdBvNwdtn4TsMQ44/jcstofLWR5cFUGCIMPhrEO52Q2++l3D1t6A+/kTTLuBrx7ZTZk72 Zop5jDOW1I3UOzEMTLjfvoODe3Udh1oDMlXQJZfsWIZ7I7J4mAmzOgQ+Kv3GxD+k7Uui5x 6KDhaOfFy6zDaydb6AIOzrrhgTRJm1o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1732564275; bh=7cKmBtGYZs9NVjBUD0MdkFIIrOhtFk6MBLGLSc+nzk0=; h=Date:Subject:To:References:From:Cc:In-Reply-To; b=o1aeNU4YF3NP4gntXfvZ/YkR4R9iEDnx/euGlPdmmI+o9muQ3H06Az6Sc+diVd072 pSsan6+91Xur4SDoiYhRDRIFFBlJ2vi06LSkT+wt2weo+CDZ7Ntym1Wc9DjvWTk2N5 y5LKqcZFguCv8JCVWKLxuDA5sJ0zFpqzlr+ebeas= Received: from [IPV6:2409:875e:a030:1001:14::e66] ([2409:875e:a030:1001:14::e66]) by newxmesmtplogicsvrszb16-1.qq.com (NewEsmtp) with SMTP id B439408D; Tue, 26 Nov 2024 03:45:03 +0800 X-QQ-mid: xmsmtpt1732563903t4lyv5end Message-ID: X-QQ-XMAILINFO: M465k96S+ahuh98II/Gmqk/gedihYW0scNWWKMuz0Rqj19yYFnqiNiYbrgZrSP 1yOM8ncmKhJJrtLWRW9r7EsRTEqhO0MchcT0jBNFUcD2XAJp2M4s/t7gLYs3dncX4qY1lwyWvYbp vifc3k5Vek7H3f0gCbIp7Ulti9CRzTOPdM3vc+ZTbvA0cIcZ9gPSgrcVFrhM7t2Q5X6y4IRZxM4o Gg+rJBsEH/pY+9HHnq/OdgA7wnq1dXDoQUGEjrjG5ixqnTCcsm9xXOviKvXnbj64GpYnJgLvBRBE BYrRA/o6SuyQmb5KsT5yLiTx8YaZp2nYTufNO/TVMufOtgDYv7syOHQQYaXIp998eEvKhW/smOhG 3xItFG5QarKLMfuqZcKNM7+P36yUGKm3gqxW08L7p1FceoFW4cQL5PE7Bw2DtptrJy9RDc01M+Aw sBurOFmRs9SGbwBJJ/8/fs/Ze4f+slGnIJ0Oc88O7mKAoy4nsgZGJxcx7jeFpbAbr8EwET8oCUsq zZ5Xs5zn84Xt01w19Q395Xhi8pF2j/3ssrmTaG21951t8NEYh9pfugq52f09I6piegNWsI+U+iBC D9pdtYW1EAoFje2Ok2vqLK1+hd1aU1fOmtEJZRumSp85YGnMNnDAXM1WyF2pnJzKh/RnVS+1Quwh OgfFY67uyQgjFRjsF0txvmMrLHIhwXW7cUgpTMXk1ZPI5EIvWv9uHZttayD5myLIzR3n2hh0PBH2 prMoCAWdAyPebFnDYFG9ottfGaIudZ2DihWnavvWt7BklmbYFO5ap8NJB6o9SIaj9G+dTwJizhpT uO562UUPY5kyhdH2NGBuEj7cxm6pppgjvyMksb1w7YJw+wNdwOWbAOIZYCDSOOBUnViVYcmoflHp b/4C5yCQgrEBWsggZtnMc1Sw0Jwm4SZiXVYPA1tuGIGlmyB78C/70AVLEd7XbmQh1wg2G28BBjWs Sc8QMJ4es9+5VglqHiaoHGQtjeGCkDmmhSMguBr7A= X-QQ-XMRINFO: M/715EihBoGSf6IYSX1iLFg= X-OQ-MSGID: <43f489d2-1019-4d5c-a0d9-600729388731@qq.com> Date: Tue, 26 Nov 2024 03:45:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/mempolicy: Fix decision-making issues for memory migration during NUMA balancing To: Michal Hocko References: From: Junjie Fu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, dave.hansen@intel.com, gourry@gourry.net In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3D07A8001F X-Stat-Signature: mgja1skyqbght8gf5a7k4sxatozsh4uy X-Rspam-User: X-HE-Tag: 1732564277-43910 X-HE-Meta: U2FsdGVkX19gYqHoaclreHJ5qXcUZ4MpzlN1SugBMFcwCcdGQ9AXSmDDcyHn/pMQBvdlbnjl+IVaA8151A6539PBwUD6LBG+f9XyzQg5Sn8pMV1i9RJxQAsRYJhfXGy2ENfpeLroJOxiwYrTPy6gF21oSIQ34sz3DHeJXWKVMEyi6Ezycwhm98qGPIUXeOdCuPIY3G5LtmzMlD22gDASVWPw4C1W8J4nxlZv+91rRTUf9/qqLe9/xrd9bt1luEhBVucwBwK+7T+Uw9Y8SFbox1OCmrb57MjmvAinuVL/2rLZNMNNuaGZIFeegLpkd5HBGR6J5l/hrEUApnV/Ujqrnum1540ljT67WFpTRNEQjtc6W9GF4vLg3pgc/gqFld9EhVLfMaqyQh3MzUeXrf2xtI/w/WBK5ts/DDJLnPIYqaTjJWz5BuKuG8my2SGm4ORcIG/vOm44Jr7gBFH5IXaFvEDaae5SJ76Vg3HIhUP35Obgu49izWSVDDO4I5uKinx9gKdWvko5he/7WHt6QZzSkN6BbI0kzSIgoyU3iwiv0A4BLwmUC9bM8qZifPzJ4SSyKftuEJG1QlikNsEX1Lg8kQ3ESAYPv3tvj+v93OxCT9fqYVHwCqRrTHkBJuf8DrIxvdmsEm2AtOWv5oRRrSxIEyYA8Uiz72K49SqORBNX7rxFR+hvDEPFOwlmLbFzL+BA5gHRLcOxKQKaPy9LubBwm5Y1nNhmDiEHYP9VuONTxFiQU1ODltU1piWSQQXjdXhtd3rvuENUzqXKishCWfO9UF672XojR9SUsimT+SwcT1H3webjqChuQqgXRAO8+EIKgexcAasaqSFEmYmXmogBZdzGC3grPbhy+6sHOyr/IMOd3bRmn4IGno/N2drsRyzSdChpmafI4Y3kY0jdWRVXBeXVgjYR9qmi2ffCrHg37BF97oFYAUWsOE09aPB1jKlApT3vnxe4VUBrz7U5BfL xTkFmUdT 5eMQnLiP9INGd5kkWbeqyhL/WdwdWNJJQAdKYG/TU0NSxp0Hf3uPT6TLUxIdljreYcdZzWR0Nnpo0RFBZQ+AskxfCs59gHqBhaY95uQyWcAz1+si8KjEBQrHhmuJPK3Q1yCEyZTo9PqW8Vglz05MM8dCqN7VL+NntBl2k30Nl/fsyCleQzV4RD65N3SX2hRWoqYMNcBeeVvnc7BE7yi00cTF/e1q9JkMQ726fYHknzjHDa/X3gBfIbgxF9Zbwe52TrGEuqdYPVjUH7lW2O2T1w7wq04SDLMj9+wDruI9E9YdV9rU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.005138, 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 November 25, 2024 at 19:33, Michal Hocko wrote: > On Sun 24-11-24 03:09:35, Junjie Fu wrote: >> When handling a page fault caused by NUMA balancing (do_numa_page), it is >> necessary to decide whether to migrate the current page to another node or >> keep it on its current node. For pages with the MPOL_PREFERRED memory >> policy, it is sufficient to check whether the first node set in the >> nodemask is the same as the node where the page is currently located. If >> this is the case, the page should remain in its current state. Otherwise, >> migration to another node should be attempted. >> >> Because the definition of MPOL_PREFERRED is as follows: "This mode sets the >> preferred node for allocation. The kernel will try to allocate pages from >> this node first and fall back to nearby nodes if the preferred node is low >> on free memory. If the nodemask specifies more than one node ID, the first >> node in the mask will be selected as the preferred node." >> >> Thus, if the node where the current page resides is not the first node in >> the nodemask, it is not the PREFERRED node, and memory migration can be >> attempted. >> >> However, in the original code, the check only verifies whether the current >> node exists in the nodemask (which may or may not be the first node in the >> mask). This could lead to a scenario where, if the current node is not the >> first node in the nodemask, the code incorrectly decides not to attempt >> migration to other nodes. >> >> This behavior is clearly incorrect. If the target node for migration and >> the page's current NUMA node are both within the nodemask but neither is >> the first node, they should be treated with the same priority, and >> migration attempts should proceed. > > The code is clearly confusing but is there any actual problem to be > solved? IIRC although we do keep nodemask for MPOL_PREFERRED > policy we do not allow to set more than a single node to be set there. > Have a look at mpol_new_preferred > I apologize for the oversight when reviewing the code regarding the process of setting only the first node in the nodemask for the MPOL_PREFERRED memory policy. After reviewing the mpol_new_preferred function, I realized that when setting the memory policy, only the first node from the user's nodemask is copied into the corresponding memory policy instance's nodemask, as shown in the following code: static int mpol_new_preferred(struct mempolicy *pol, const nodemask_t *nodes) { if (nodes_empty(*nodes)) return -EINVAL; nodes_clear(pol->nodes); node_set(first_node(*nodes), pol->nodes); //only the first node to be set return 0; } Due to my previous oversight, I mistakenly assumed that multiple nodes could be set in pol->nodes, leading to my incorrect understanding. Therefore, the original code is correct. Thank you all for your responses.