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 9653FC433EF for ; Mon, 14 Mar 2022 01:04:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C73996B0072; Sun, 13 Mar 2022 21:04:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C22946B0073; Sun, 13 Mar 2022 21:04:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEA2F6B0074; Sun, 13 Mar 2022 21:04:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 9C0336B0072 for ; Sun, 13 Mar 2022 21:04:06 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 67A9E2291D for ; Mon, 14 Mar 2022 01:04:06 +0000 (UTC) X-FDA: 79241195292.01.7C8C4D4 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf12.hostedemail.com (Postfix) with ESMTP id 49CB040023 for ; Mon, 14 Mar 2022 01:04:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647219845; x=1678755845; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=ySgDxotKJSJVAy+FBzbr2z38YaeYDTtZKQwAu4elqtM=; b=VnmaF1w2InBFnk6/UiOM3JRo5spQlCMHCJ4XUx/CjlAI+abg7gOHHqV4 s7mRBm6Xa9RrB66DpGRX10cPeUrShigjrECMnAUODxyFSeVHPEe+LokUf lhJMUliNV82KO16zszLh9QlRmDU1vQdyNZT26frb7loCiMoxY7YtyYrik zwnpwQENAjmXdQSKq/yH/vnXIiUZk3OTZJHGKVqKcTMVfr9B/PyykedSv no9HElsPYMSYjgXJUVXEsvt3JEqGVD9drBsvZBfWzmi8S++I1HC7u4SQb 19Y8O29/OCTSxLwnTFvqbhFROeCH0OJKmsT/G3Y49s189ksS68lNm89Cc g==; X-IronPort-AV: E=McAfee;i="6200,9189,10285"; a="255864939" X-IronPort-AV: E=Sophos;i="5.90,179,1643702400"; d="scan'208";a="255864939" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2022 18:04:03 -0700 X-IronPort-AV: E=Sophos;i="5.90,179,1643702400"; d="scan'208";a="556160523" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2022 18:04:01 -0700 From: "Huang, Ying" To: Oscar Salvador Cc: Andrew Morton , Dave Hansen , Abhishek Goel , Baolin Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: Only re-generate demotion targets when a numa node changes its N_CPU state References: <20220310120749.23077-1-osalvador@suse.de> <87mthxb514.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 14 Mar 2022 09:03:59 +0800 In-Reply-To: (Oscar Salvador's message of "Fri, 11 Mar 2022 09:39:52 +0100") Message-ID: <87czip73b4.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-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 49CB040023 X-Stat-Signature: sijkk6dymsfjawmfhpr3ehzttaza37za Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VnmaF1w2; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf12.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=ying.huang@intel.com X-HE-Tag: 1647219845-783239 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: Oscar Salvador writes: > On Fri, Mar 11, 2022 at 10:24:07AM +0800, Huang, Ying wrote: >> It may be unnecessary to be fixed in this patch. But I think we need to >> cleanup the kernel config dependencies of the demotion code at some time. > > I am glad you brought this up because it is something I have been > thinking about. > I already added it in my to-do list, but I would do it in a separate > patch if you do not mind. Thanks! > Now, let us try to untangle this mess: > >> 1. Even if !defined(CONFIG_HOTPLUG_CPU) && >> !defined(CONFIG_MEMORY_HOTPLUG), we still need to allocate >> "node_demotion" and call set_migration_target_nodes() during boot time. >> >> 2. If !defined(CONFIG_MEMORY_HOTPLUG), we don't need >> migrate_on_reclaim_callback(). >> >> 3. We need defined(CONFIG_NUMA) && defined(CONFIG_MIGRATION) for all >> these code. > > Back in the early versions [1] I asked whether we could have some > scenario where this feature could be used when !CONFIG_MEMORY_HOTPLUG > [2]. > The reason I was given is that in order to bind the expose PMEM memory > as RAM (add_memory_driver_managed()), we need MEMORY_HOTPLUG. > > Now, as I said back then, I am not sure whether PMEM memory can be > exposed as RAM by other means, but as it was pointed out back then, > it really looks like we, at least, need CONFIG_MEMORY_HOTPLUG. > > Ok, so we have our first dependency: CONFIG_MEMORY_HOTPLUG. On host machine, PMEM is always exposed via memory hotplug. But later on, we found that for guest system it's possible for PMEM to be exposed as normal memory. Best Regards, Huang, Ying > Now, about CONFIG_HOTPLUG_CPU, it seems that that is not a strong dependency, > as we do not need cpu-hotplug in order to use the feature. > > We definitely need CONFIG_MIGRATION and CONFIG_NUMA though. > > So, we have something like: > > - Depends: > * CONFIG_NUMA (obvius) > * CONFIG_MIGRATION (to migrate between nodes) > * CONFIG_MEMORY_HOTPLUG (to expose PMEM as RAM) > > Sounds about right? > > [1] https://patchwork.kernel.org/project/linux-mm/patch/20210401183221.977831DE@viggo.jf.intel.com/#24099405 > [2] https://patchwork.kernel.org/project/linux-mm/patch/20210401183221.977831DE@viggo.jf.intel.com/#24103467