Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp778833pxp; Fri, 11 Mar 2022 14:55:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQAjw67rG0K0IPeSTkNIhtQWkPEX7eXtiybs1Y64xWZ2q/ccHiaweK662fZpjK/CY9G3HI X-Received: by 2002:a63:83c8:0:b0:380:bb85:56d with SMTP id h191-20020a6383c8000000b00380bb85056dmr10295252pge.541.1647039342361; Fri, 11 Mar 2022 14:55:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1647039342; cv=none; d=google.com; s=arc-20160816; b=LhCfR56JVaqsVByQhVRyeny4rq6sZnup/4VCvdL7NZRmw9TomZe7s0poNramOEugKp HydkI0ZiFQYzEz/OA32ByorBkid+l2C61frOGnqIn3YjBFmGDOiGIIAjZSZZnZ5pVRfx djxvSWmQKE8+jynHS+9TZnocvqi3Rr6vV94vrPm81kzu3b259a3HrixuFG35iK87o/QD N5Y+Apvl1JIf4DKIYh6nEH9mAeBP4gTiPe80t6S+HybA/NxAi42aXkpsftz0+iCVKPZ3 3xkC9UnYtxLNdiYU9GpTzui3S/HT9BEJQhGU/K+koCnuw1/gAL8cBIhoF371fTD2RkYe jHXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=4kMBg/daLFkH2x2KCJjhOIPsN9f09ivU6wsaabQrRP8=; b=l2ombyS97fJrFOieZlJpqZVP5CsKjyCCH2M3WeDiH/e082nfnabjf9QMUYk490sHkM hQxsWUlS7jli6h2aeh0JE2aEC3hQzMmn61Y4X9fcR806qdPCr9Tw2qRnlGIVvX8JXOKk Q9Q7tkRyH5swgHHg433ardhDuvee87wcOOJGqWITodrYaBb423/IabeKUoo+tInKEaML RG8DyOSYiQSaIAAwRSqLWQ6E1pM0SJHTduOdith0Tya4lSdgp6cfzD2GhgUFI6/16dYo TYawf4qSkzijSrJgSxgWjbmSd+LRk8dOhLsL1Ff/7qXa1lwJ4OGMc5ECCKvsSor5Fbtx Gtsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W78cKCIf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t6-20020a17090a5d8600b001bd395ddfa9si9164496pji.10.2022.03.11.14.55.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 14:55:42 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W78cKCIf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8D6CA363B23; Fri, 11 Mar 2022 13:53:10 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350595AbiCKRLN (ORCPT + 99 others); Fri, 11 Mar 2022 12:11:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349499AbiCKRLM (ORCPT ); Fri, 11 Mar 2022 12:11:12 -0500 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FE4FD444E for ; Fri, 11 Mar 2022 09:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647018608; x=1678554608; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=p9BhkaxiWbSuCDwfv6fPTGlhyGO3m3RMfcZIxaye4DA=; b=W78cKCIfoRAyViAKCS75PvWOzRCbA00Ftd57ITzgMHAfpaB6SlLU/3xe TBLPk/08PxaskTf9vWUtoodL1jZ8InSnNLXL9dkyw9gj3s/wCrKpL94jm ariPDaC5Y7e0DSh6BwosGnselrRgP5UAcTMgFaRMmYHTAYCYo0jiDUI04 C/JKCyutjhiJgEjSdd9ZX1OwYNg1BPuq4+cuuSvpmeBnkcEsAHD3O3ZK2 NkxSoAifmyXp9pYubJjsLVvqwmNs08aUzBYWPG7V8NMr4hYVHDNFUuwho DPvP/+4bjuEg9zSGh1xb6qrRswlrKPkcnSqVNVdo5Dh1QLezNtr+v2XQm Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10283"; a="316333577" X-IronPort-AV: E=Sophos;i="5.90,174,1643702400"; d="scan'208";a="316333577" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 09:10:08 -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-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.