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 AECFEE6688B for ; Sat, 23 Nov 2024 22:16:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27D7F6B0082; Sat, 23 Nov 2024 17:16:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 22E056B0083; Sat, 23 Nov 2024 17:16:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11BD46B0085; Sat, 23 Nov 2024 17:16:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E6CAA6B0082 for ; Sat, 23 Nov 2024 17:16:02 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8D74BA1AA4 for ; Sat, 23 Nov 2024 22:16:02 +0000 (UTC) X-FDA: 82818768522.15.736F5CC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id BEC7B20013 for ; Sat, 23 Nov 2024 22:15:58 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aOZPOlZt; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732400160; a=rsa-sha256; cv=none; b=sJ2iXY3mVBFlnZBPdK/7sgNB+sRlFy1bt33T8nbA1THh0zHWKjGvJ+8iOB4FNMdSha9CQ5 dNMhMWBi/8qQmjicaSDAUt54+OF4YiDIF7v6GrjgyuNY0db5bIJ1tEpbhKzGwnkF+WvsBv mIdWp2oKCUxr5HnikpQO7W9YvDWaOtY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aOZPOlZt; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732400160; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JYR0lfiZ1TWLALwPOMCeGprcH2BZa7iQPqABEcTjuZQ=; b=gcKJ48DLqKG4oC+mWXTf8nKplDL1odM9Dfb9Bl+vK1ysTKmwjV+pQlkGhTZUMJ8TRo6QVA K8zv/Z19l/oewZmaercbBYstdrUNj76LaNYCDPfh2ZFy6+3U4SqMaiOg5AYhaV6kjWxsXn pVDYXFy42clzEK6Z8Y/3fObE1sh6Y4A= 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=JYR0lfiZ1TWLALwPOMCeGprcH2BZa7iQPqABEcTjuZQ=; b=aOZPOlZtqy6H42q8zLm4DaFwNf gSvRpOoyp2ZAk/7hTHPLv3cEjVjJQfcAXWS7/BDQxwEypfLUFOoq+Qbt/21/VcyxjMGHSBtfggyRN ldtucx8OHB60gx6HtylhwrH5E4r6T48P4i2xdPU6b4EbZr5nu2oRoxUWFfHvdSpjSZkOizEypoM+Y 66d8B4X+NLm6TzEiKVS9KZuXJZleAynXaBf4NKWE9CzgcG46SgPytEQmFKn5lHiqPLkN1SevqsQ07 g6N/M3YplKRHCydPPgXztLyjkaAyZ0Dvh5dxAKpHHodMsR1VKuYKDA9NzsadgkX2K76bPIKf5XYpZ MzAqFLYg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tEyQ0-00000009hNs-1VyV; Sat, 23 Nov 2024 22:15:56 +0000 Date: Sat, 23 Nov 2024 22:15:56 +0000 From: Matthew Wilcox To: Junjie Fu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, dave.hansen@intel.com, mhocko@kernel.org Subject: Re: [PATCH] mm/mempolicy: Fix decision-making issues for memory migration during NUMA balancing Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: BEC7B20013 X-Rspamd-Server: rspam11 X-Stat-Signature: qh87bryym16bdkkyp4eo6ehh9t4yi4r5 X-HE-Tag: 1732400158-308807 X-HE-Meta: U2FsdGVkX190yZo0ar4Unz9Y+3KI3O3yIj6r/UqGWM/JApXzuKNSJff9ZjmuHCwbRhDh169LxL3yDQbZXfVy40MGCIcQEbtDv+lCmCPnEXEJhv3fsfndLzuGxOpK2OgHgs0w26kG3teqW+BTlAVt/+e4Nqx8s/c5D2J9Ijlfkf2eZYBGaKEjPLlMQmIae4nSRkrXWD6+Lg9kwNpkrrUZd8fIr1MO98OCeqBD0D0Qg0wn3NWcL0lQsNUiA1b5nmFUIkYT85o4nlDA3nLUHPCWIdY2nOpmjxrRTR1fM3pXNnTwcsHwZjPosiW91iESu0hB/lKO3R2bxkzHpQq49+gT6JKr5SEPuk6hjnwnEr3LPun1bAKZiHISZg4b9/Rsfoe2v5g/Y761ae67vahXNQPbfNYACp7h6SIRMsK0xbvgzLexiE8hwRSqT9VwRlfah4Mq84X5cUpXhNSej8pcbDSRNBSPyAmjlI8JBaReKdF/l7Qa8rt57bMLatZ2djgcBANI27sOka/os6GP4XLd+Khn4LpYsyFXfByFKzsAx4Cza+zgqxUlQC43wpbesjC1SB1ZLDOC9vDPU6r3F4MmT68PlCB9pF9lLunaAs9n1loYWaj1lUEWvwqbOWJjvivKRFixWg4xwFy9bFAMiC3AY87t4nSmYmQbr7IDp4fxFPuyP59quWJ1GUS0j53iye5YzjUE6IHOn/1k3Yf6oIOjrsXYhCUoKUqlBWm/gCQY+dtn6YgIbQiX0I+Zplxv0xnaNxyU0Nb1LKVYf7xfjkxW8qpEgi5/AabzDXF6kDgv2SEkyo1uPbxfBQ22LkUlTSHsnx2giSQCxB+oFqVqNl6nFslrhX4TvuwEtf3R1yWliwnKXeiwLHKZ80alFZeyVyk2u2k1S7W46WL99Jr0oe1joPkn3H58AQvhkIWKgS2zbbSbD3pfi99E3MFW6Erj4RmkpC7t3wzDivhOY+j0B5IXS/7 6d/sJ84f +R2YKrzkP15e+ut7rPkjbtC438OGL5gAu4G3bJ0dZ/4VEHtWTjU8+ykfLhMUofPwztpzsjSZcqaRU/g35XKE4pstLz8/rkcyebeFoRmsS0Hc0//4aka+1ehxecNyYHPWvN8UBoI+kpMdOv+NxJgCrgxHgIKT8nd9Ke3KhA87mgpwIoqD/h/iv7O7tigB7xDuOyHT1exZvs3d3YMl9GG2qG2mQ70z3PSYVXqUU 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 Sun, Nov 24, 2024 at 03:09:35AM +0800, Junjie Fu wrote: > 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. I think you've found poor documentation, not a kernel bug. If multiple nodes are set in PREFERRED, then _new_ allocations should come from the first node, but _existing_ allocations do not need to be moved to the new node. At least IMO that was the original intent of allowing multiple nodes to be set. Otherwise, what is the point?