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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A170C433EF for ; Tue, 28 Sep 2021 01:22:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 98F5A611F0 for ; Tue, 28 Sep 2021 01:22:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 98F5A611F0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 04331900003; Mon, 27 Sep 2021 21:22:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3610900002; Mon, 27 Sep 2021 21:22:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E24F4900003; Mon, 27 Sep 2021 21:22:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id D2386900002 for ; Mon, 27 Sep 2021 21:22:04 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9A85531EBF for ; Tue, 28 Sep 2021 01:22:04 +0000 (UTC) X-FDA: 78635230968.19.1E7CF25 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf12.hostedemail.com (Postfix) with ESMTP id 80BAE10000AC for ; Tue, 28 Sep 2021 01:22:03 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10120"; a="224631876" X-IronPort-AV: E=Sophos;i="5.85,328,1624345200"; d="scan'208";a="224631876" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2021 18:22:02 -0700 X-IronPort-AV: E=Sophos;i="5.85,328,1624345200"; d="scan'208";a="553706932" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.159.119]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2021 18:21:58 -0700 From: "Huang, Ying" To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Dave Hansen , Yang Shi , Zi Yan , Michal Hocko , Wei Xu , Oscar Salvador , David Rientjes , Dan Williams , David Hildenbrand , Greg Thelen , Keith Busch Subject: Re: [PATCH -V2] mm/migrate: fix CPUHP state to update node demotion order References: <20210927081100.475075-1-ying.huang@intel.com> <20210927174722.6ca9bc6a63bb50da7754bdaf@linux-foundation.org> Date: Tue, 28 Sep 2021 09:21:56 +0800 In-Reply-To: <20210927174722.6ca9bc6a63bb50da7754bdaf@linux-foundation.org> (Andrew Morton's message of "Mon, 27 Sep 2021 17:47:22 -0700") Message-ID: <871r59v6iz.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 80BAE10000AC X-Stat-Signature: 1e379ycudqdwqu549tfpata71eyrwkh1 Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf12.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=ying.huang@intel.com X-HE-Tag: 1632792123-251400 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: Andrew Morton writes: > On Mon, 27 Sep 2021 16:11:00 +0800 Huang Ying wrote: > >> The node demotion order needs to be updated during CPU hotplug. >> Because whether a NUMA node has CPU may influence the demotion order. >> The update function should be called during CPU online/offline after >> the node_states[N_CPU] has been updated. That is done in >> CPUHP_AP_ONLINE_DYN during CPU online and in CPUHP_MM_VMSTAT_DEAD >> during CPU offline. But in commit 884a6e5d1f93 ("mm/migrate: update >> node demotion order on hotplug events"), the function to update node >> demotion order is called in CPUHP_AP_ONLINE_DYN during CPU >> online/offline. This doesn't satisfy the order requirement. > > What are the user-visible runtime effects of this error? For example, there are 4 CPUs (P0, P1, P2, P3) in 2 sockets (P0, P1 in S0 and P2, P3 in S1), the demotion order is - S0 -> NUMA_NO_NODE - S1 -> NUMA_NO_NODE After P2 and P3 is offlined, because S1 has no CPU now, the demotion order should have been changed to - S0 -> S1 - S1 -> NO_NODE but it isn't changed, because the order updating callback for CPU hotplug doesn't see the new nodemask. Now, if P1 is offlined, the demotion order is changed to the expected order as above. I will update the patch description after adding the above description. Best Regards, Huang, Ying >> So in >> this patch, we added CPUHP_AP_MM_DEMOTION_ONLINE and >> CPUHP_MM_DEMOTION_DEAD to be called after CPUHP_AP_ONLINE_DYN and >> CPUHP_MM_VMSTAT_DEAD during CPU online and offline, and register the >> update function on them. >> >> Fixes: 884a6e5d1f93 ("mm/migrate: update node demotion order on hotplug events") >> Signed-off-by: "Huang, Ying" >> Cc: Thomas Gleixner >> Cc: Dave Hansen >> Cc: Yang Shi >> Cc: Zi Yan >> Cc: Michal Hocko >> Cc: Wei Xu >> Cc: Oscar Salvador >> Cc: David Rientjes >> Cc: Dan Williams >> Cc: David Hildenbrand >> Cc: Greg Thelen >> Cc: Keith Busch >>