Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp413574pxb; Sat, 18 Sep 2021 06:30:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3ZtVyN+9/qLeZhGG7iitAAVNLOxIQBe1tBKsg3r8oCHpLX4/4ve0+HnE00jyulRFi/YwT X-Received: by 2002:a17:906:2a0d:: with SMTP id j13mr17498206eje.545.1631971813113; Sat, 18 Sep 2021 06:30:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631971813; cv=none; d=google.com; s=arc-20160816; b=T8xXupj6nU5wt6+qM1VgS7sPXdejAQOyEF9XHnAn1D5KEmo6y8/fn8YdgVODjel4of L4Xx1T5Um8WaD9oinnLBv8TjnhCVNoBfoBhW2j2IKDDJbZZ1T2exhX2IxTyLpUMCcctU sNeusH3NSjETZc+JAVY3ZIRJi8yG6bW2oWD4JlVilPE+2a2mYgql2aiVGQYyBcsLrMKT 2Mb2vapS0BnqIsh27/MZeaBrsAjiXquC8V3HQvwitIUEGwUAtFTIfqyL8u8ZvstLpZsG 2Phm3l3zcVVMmLTbFiHUbX73HFtnkzqUYSTFqeVaZJJ8pdc93m6mkOpiIUJrzeECnLUq pb9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=E9bGpR660axRQZBkfJvP8FjZHV0D0Dg5A4d20023CaE=; b=KLaOwrhA4Se9KE0SOkT6syIUjymsYxI0T6MerN4oDVKrsUn5i2F6wQ1RTulC/9vpVV OsfGPtAENciStaXBtt8zwfbjMBROlO2fFMcI0UFdG3yvilnnx21mZ8rbIAmYQBr8PrSf UO78C0Itu4GkTv8mQqbJOn74vxnpgXwPGJTYbUL7vFa7a1WKhKmB/bVL5nFgbiW/JUNT xWqUPR1fJE8e+R7qA4Y3EZfMu6dqJMZXqVKV+nPXjPRHEiLpWkWvdfbOoAoxw2N093hX ulbbn4O+HLgCa7HrF3HBqV6pmSSzCFoyZ4904AGSjnteK6ci8aWgsFLovq8wW4VqS9FX DmTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j23si12365525eje.21.2021.09.18.06.29.48; Sat, 18 Sep 2021 06:30:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239463AbhIRG61 convert rfc822-to-8bit (ORCPT + 99 others); Sat, 18 Sep 2021 02:58:27 -0400 Received: from mga01.intel.com ([192.55.52.88]:47115 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232728AbhIRG60 (ORCPT ); Sat, 18 Sep 2021 02:58:26 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10110"; a="245319229" X-IronPort-AV: E=Sophos;i="5.85,303,1624345200"; d="scan'208";a="245319229" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2021 23:57:03 -0700 X-IronPort-AV: E=Sophos;i="5.85,303,1624345200"; d="scan'208";a="546843351" 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; 17 Sep 2021 23:57:00 -0700 From: "Huang, Ying" To: Mika =?utf-8?Q?Penttil=C3=A4?= Cc: Andrew Morton , , , 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] mm/migrate: fix CPUHP state to update node demotion order References: <20210918025849.88901-1-ying.huang@intel.com> Date: Sat, 18 Sep 2021 14:56:58 +0800 In-Reply-To: ("Mika =?utf-8?Q?Penttil=C3=A4=22's?= message of "Sat, 18 Sep 2021 07:04:41 +0300") Message-ID: <87bl4qcqx1.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=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mika Penttilä writes: > Hi! > > On 18.9.2021 5.58, 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. So in >> this patch, we added CPUHP_AP_MM_DEMOTION_ONLINE and >> CPUHP_MM_DEMOTION_OFFLINE to be called after CPUHP_AP_ONLINE_DYN and >> CPUHP_MM_VMSTAT_DEAD during CPU online/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: 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 >> --- >> include/linux/cpuhotplug.h | 2 ++ >> mm/migrate.c | 8 +++++--- >> 2 files changed, 7 insertions(+), 3 deletions(-) >> >> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h >> index 832d8a74fa59..5a92ea56f21b 100644 >> --- a/include/linux/cpuhotplug.h >> +++ b/include/linux/cpuhotplug.h >> @@ -72,6 +72,7 @@ enum cpuhp_state { >> CPUHP_SLUB_DEAD, >> CPUHP_DEBUG_OBJ_DEAD, >> CPUHP_MM_WRITEBACK_DEAD, >> + CPUHP_MM_DEMOTION_OFFLINE, >> CPUHP_MM_VMSTAT_DEAD, >> CPUHP_SOFTIRQ_DEAD, >> CPUHP_NET_MVNETA_DEAD, >> @@ -240,6 +241,7 @@ enum cpuhp_state { >> CPUHP_AP_BASE_CACHEINFO_ONLINE, >> CPUHP_AP_ONLINE_DYN, >> CPUHP_AP_ONLINE_DYN_END = CPUHP_AP_ONLINE_DYN + 30, >> + CPUHP_AP_MM_DEMOTION_ONLINE, >> CPUHP_AP_X86_HPET_ONLINE, >> CPUHP_AP_X86_KVM_CLK_ONLINE, >> CPUHP_AP_DTPM_CPU_ONLINE, >> diff --git a/mm/migrate.c b/mm/migrate.c >> index a6a7743ee98f..77d107a4577f 100644 >> --- a/mm/migrate.c >> +++ b/mm/migrate.c >> @@ -3278,9 +3278,8 @@ static int __init migrate_on_reclaim_init(void) >> { >> int ret; >> - ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "migrate on >> reclaim", >> - migration_online_cpu, >> - migration_offline_cpu); >> + ret = cpuhp_setup_state_nocalls(CPUHP_MM_DEMOTION_OFFLINE, "mm/demotion:offline", >> + NULL, migration_offline_cpu); >> /* >> * In the unlikely case that this fails, the automatic >> * migration targets may become suboptimal for nodes >> @@ -3288,6 +3287,9 @@ static int __init migrate_on_reclaim_init(void) >> * rare case, do not bother trying to do anything special. >> */ >> WARN_ON(ret < 0); >> + ret = cpuhp_setup_state_nocalls(CPUHP_AP_MM_DEMOTION_ONLINE, "mm/demotion:online", >> + migration_online_cpu, NULL); >> > > You changed to _nocalls variant, how does this handle initialization > for cpus present at boot? You are right! Thanks! There are some discussion about CPUHUP in anther thread as follows, https://lore.kernel.org/lkml/CAAPL-u_Tig1jK=mv_r=j-A-hR3Kpu7txiSFbPR3a8O1qhM1s-Q@mail.gmail.com/ I will wait for discussion in that thread too before the next step. Best Regards, Huang, Ying