Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp362208pxb; Tue, 1 Feb 2022 01:16:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJzW0PoG0az+yoZMC8oyk1HYEt1n9IIw0ouSuLO9Wdurv2sczxDykOCRrVvGPj7iE62FYMqM X-Received: by 2002:a50:9dca:: with SMTP id l10mr24207478edk.311.1643706964314; Tue, 01 Feb 2022 01:16:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643706964; cv=none; d=google.com; s=arc-20160816; b=pqw03d+TsYk3XkOwc98SUfgsGxdy7EbfFfrnupFVooECKyJYjx6vdPbRkq8feQDAwu sfI5cdm1ZzMctQIrDJ2PthGzKTG5wjznbX58QLNxB63aRv9Od2oAQPKevfiYVAFFFtz0 IfBgZnvyQMKqkK3V9B6KZM0eU5UEh4/rT7biroshbD6dwlcnq5CljJr0TiL/Z40V010b 3zoCNUehVvrrp1YyahyCP0UvyBCfsAw7VD1J2n2YBTAxoXqU4qlu/8sU7qD4lSraBhv+ FYdxU4Uy8BM64fWvEorNEZOXNtL0HFxmZCv8NUF/r7NSoXkhHkJGLOXdycKqqFXlGdkR G0cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature; bh=wfU2MWHxMWieksohhf8/pE41XOfN2Vwmo7xAr5Y2Ls0=; b=eA0lJFmwdlv+WQHvrPc9T6HnY3SvPqwJZT96hQWobP8VCpxMJc9YVRFSblgoW7EYm4 l7lgFdx0j9xzJyNKbe1hlvS8ZeRmpGGHHRScBSnUbtvs8PDPoLuT1bbWwNVjcFnkPwIx /aVSEM1IrRnsPELz96xtAgr821JDvPqf1iUF7crQuzu+9KFw6SqS+WZrECnhxPoMfoF0 bvnuszKJkEAcbEjE19mGRO8Y/hJWJSkTTpDmM6fBD4khJIv/1dfaFtuZBBM4ilQP/lKU KT5j0h60tlaZhy544PqHL3efXgq8qy5wOykX++ZDwLPePCrrlB4R50wZbNyW3gBjMeA4 AHhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W3gWegH3; 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=pass (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 sc10si11481624ejc.290.2022.02.01.01.15.39; Tue, 01 Feb 2022 01:16:04 -0800 (PST) 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; dkim=pass header.i=@intel.com header.s=Intel header.b=W3gWegH3; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353606AbiA3BHX (ORCPT + 99 others); Sat, 29 Jan 2022 20:07:23 -0500 Received: from mga03.intel.com ([134.134.136.65]:11829 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232795AbiA3BHW (ORCPT ); Sat, 29 Jan 2022 20:07:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643504842; x=1675040842; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=HAtiV9xYaZQgR7COoOn8hvU9x5+DlnyBUlJJ0ycfjXE=; b=W3gWegH3kfSl8Ck5HF77kSjBi5o7dhKR7Rh95gzsPNnFi57YEBjAyp2N u6bNWAVqs1ENqas8tTm31qY3RRVB5UNtr8ruHqT7RSV3VN+0NtWvuF97O ZgeHEG7dyhzncq2ZJcIy0/6BqnA63SpK4akqMmpbS8blim2oxdj8BM0i5 VZxrMW6qyz++dOjF4S8485S5T7dIXs5CqD2pDaTBlqc8wh5e1sxUTojLF bwyqynbtg69yFISou4fpFWlJmzNcWokOT2rZuLcEH6/yagVSTXJlHJ5oV +/9oTK4RYT0nQR41AwD6sc7retl5CTQyyVB3pvGs+u0g3hpMC/5/A32fk g==; X-IronPort-AV: E=McAfee;i="6200,9189,10242"; a="247256806" X-IronPort-AV: E=Sophos;i="5.88,327,1635231600"; d="scan'208";a="247256806" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2022 17:07:21 -0800 X-IronPort-AV: E=Sophos;i="5.88,327,1635231600"; d="scan'208";a="582235464" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.11]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2022 17:07:19 -0800 From: "Huang, Ying" To: Peter Zijlstra Cc: Srikar Dronamraju , Mel Gorman , linux-kernel@vger.kernel.org, Ingo Molnar , Rik van Riel Subject: Re: [RFC PATCH 1/2] NUMA balancing: fix NUMA topology type for memory tiering system References: <20220128023842.1946583-1-ying.huang@intel.com> <20220128052345.GA618915@linux.vnet.ibm.com> <87czkctiz9.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Sun, 30 Jan 2022 09:07:17 +0800 In-Reply-To: (Peter Zijlstra's message of "Fri, 28 Jan 2022 16:13:54 +0100") Message-ID: <87sft6rpyy.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Fri, Jan 28, 2022 at 03:30:50PM +0800, Huang, Ying wrote: >> Srikar Dronamraju writes: >> >> > * Huang Ying [2022-01-28 10:38:41]: >> > >> >> >> >> One possible fix is to ignore CPU-less nodes when detecting NUMA >> >> topology type in init_numa_topology_type(). That works well for the >> >> example system. Is it good in general for any system with CPU-less >> >> nodes? >> >> >> > >> > A CPUless node at the time online doesn't necessarily mean a CPUless node >> > for the entire boot. For example: On PowerVM Lpars, aka powerpc systems, >> > some of the nodes may start as CPUless nodes and then CPUS may get >> > populated/hotplugged on them. >> >> Got it! >> >> > Hence I am not sure if adding a check for CPUless nodes at node online may >> > work for such systems. >> >> How about something as below? > > I'm thinking that might not be enough in that scenario; if we're going > to consistently skip CPU-less nodes (as I really think we should) then > __sched_domains_numa_masks_set() is not sufficient for the hotplug case > since sched_domains_numa_levels and sched_max_numa_distance can also > change. > > This means we need to re-do more of sched_init_numa() and possibly > re-alloc some of those arrays etc.. > > Same for offline ofc. Got it! It doesn't make sense to create schedule domains for CPU-less nodes. I can work on this after Chinese New Year holiday week (the whole next week). But if anyone want to work on this, feel free to do that. Best Regards, Huang, Ying