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 19886C433F5 for ; Fri, 11 Mar 2022 17:11:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 844F48D0002; Fri, 11 Mar 2022 12:11:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CBC48D0001; Fri, 11 Mar 2022 12:11:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 645AE8D0002; Fri, 11 Mar 2022 12:11:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 4E3C68D0001 for ; Fri, 11 Mar 2022 12:11:18 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1734F222DD for ; Fri, 11 Mar 2022 17:11:18 +0000 (UTC) X-FDA: 79232746236.03.E1AE4CC Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf14.hostedemail.com (Postfix) with ESMTP id 1E615100022 for ; Fri, 11 Mar 2022 17:11:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647018677; x=1678554677; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=p9BhkaxiWbSuCDwfv6fPTGlhyGO3m3RMfcZIxaye4DA=; b=mVbSwVMYFPYT/uXYhVB2Q+Nvc/oQiy2zjo4oSooimewMZpd3tRUQ2N4T fYFOGUax34P5UV5VLmaVZx6MmeVY1YgSFV0G/Vlcw33HgMKZ6OXmmF83Z duwsZyZAVuTVAycLTZSbMb2W4cnD+X988sxm7Wuf3CuWliPy9kFrWpvY5 N9GEldOrbzNYBOit0W++vOJphJSrePPlVBGjioFqDb4H3CZC2Ppblqy7L +AnRAbnOjlKUBBIJgWd/EbhNUkQSfGBuC6qRIE7pYLJajJlzr5foRME3K SlOhCQKk+8Kc0W6d3vLc8UcLjVNHHuw/tXpMYIKqVI24PWYGElcvZCuTZ g==; X-IronPort-AV: E=McAfee;i="6200,9189,10283"; a="235563588" X-IronPort-AV: E=Sophos;i="5.90,174,1643702400"; d="scan'208";a="235563588" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 09:10:09 -0800 X-IronPort-AV: E=Sophos;i="5.90,174,1643702400"; d="scan'208";a="644988416" Received: from cpeirce-mobl1.amr.corp.intel.com (HELO [10.212.128.243]) ([10.212.128.243]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 09:10:07 -0800 Message-ID: Date: Fri, 11 Mar 2022 09:10:01 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Andrew Morton , Oscar Salvador Cc: Dave Hansen , "Huang, Ying" , Abhishek Goel , Baolin Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220310120749.23077-1-osalvador@suse.de> <20220310183951.cb713c6ae926ea6ea8489a71@linux-foundation.org> From: Dave Hansen Subject: Re: [PATCH v2] mm: Only re-generate demotion targets when a numa node changes its N_CPU state In-Reply-To: <20220310183951.cb713c6ae926ea6ea8489a71@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1E615100022 X-Stat-Signature: djzchzwpqp55rqux4oje7fotqrjqb493 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mVbSwVMY; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf14.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=dave.hansen@intel.com X-HE-Tag: 1647018676-462129 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: On 3/10/22 18:39, Andrew Morton wrote: > On Thu, 10 Mar 2022 13:07:49 +0100 Oscar Salvador wrote: >> We do already have two CPU callbacks (vmstat_cpu_online() and vmstat_cpu_dead()) >> that check exactly that, so get rid of the CPU callbacks in >> migrate_on_reclaim_init() and only call set_migration_target_nodes() from >> vmstat_cpu_{dead,online}() whenever a numa node change its N_CPU state. > What I'm not getting here (as so often happens) is a sense of how badly > this affects our users. Does anyone actually hotplug frequently enough > to care? I asked Abhishek about this a bit here: > https://lore.kernel.org/all/4e8067e1-0574-c9d2-9d6c-d676d32071bd@linux.vnet.ibm.com/ It sounded to me like there are ppc users who convert their systems from SMT=1 to SMT=8. I'd guess that they want to do this as a side-channel mitigation because ppc has been dealing with the same basic issues as those of us over in x86 land. The increase in time (20s->36s) would be noticeable and probably slightly annoying to a human waiting on it. I'd love to hear more details on this from Abhishek, like whether end users do this as opposed to IBM's kernel developers. But, it does sound deserving of a stable@ tag to me.