Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp17430882ybl; Thu, 2 Jan 2020 05:23:24 -0800 (PST) X-Google-Smtp-Source: APXvYqz+UPOu+uzIcRk2dS0Plv8zlNd0CfM1dvRYFlnK/LSP/v4DNG7S6hQCwUPN5AS+Z7imywpM X-Received: by 2002:a05:6830:1f95:: with SMTP id v21mr85444793otr.325.1577971404015; Thu, 02 Jan 2020 05:23:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577971404; cv=none; d=google.com; s=arc-20160816; b=GIR4zumwpTv5jOQA7Hs6V1NOLtTeyBMDItEZlF1gx7ww1Y07ExVNHW6n2fPDX8qk4s Bsnn/QZnfTBY1+zd0g+l9s/d4a3NxJZaTdXC+kwnccvLWlbU0O9XtNFnwoXPYxudL9DT ErSW1g1iu/lFWddpTS0zOYx0lz9hwYfHgtW8VhCqOSjHmjkXSRn0KmGJMIzyAOkeLEFZ LAFgJ3nWBTEmRJeMeUzTvGmi2D89d6/Bz54hDpi1ofW84MA5I5stsbZdXwiTrjmy2KLm 2J3S3YsPa/XkrUQWegF0KmD/kRZd0FPpgMVVczYALsU0+xKHpt69UZoy+apSwn8tXYuu u0xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=R9Pg/Fxuf5TWjzJE+/22NAEW9+FT06wj0i9+Yd1xWuQ=; b=RNgZdPrbUUJLX47Br/qFcZNVYfZfnlpaKRi8CDp7dGe+3eYypBXdGjs4NM5ke2SE3M HUga1l5Ez9/O3LnAPH5VufpEPO/KpByX1wfuz83mpnr7pESLXg1ij88FpqKNq9rOvadJ CtjHaCLckF6qo1yJV2qHgFas3BhRpR8APsgU2oz/6Y4e9+hgdY+3yY8bdr47z9rO1Pyn UV2dgfpJSxBMXhImCelnB9S0Nz++JMuiV3E9DHu3hjnvV/sbLVTCx7XL3EFZfkib8iDZ QkH2GQ/pJ+RcuiLENLI2ZCY7woI4U8lryGiF/Wzobv3wNnB9lxO96EjVL6IScK6L1Ati OIKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n7si28465011otk.277.2020.01.02.05.23.11; Thu, 02 Jan 2020 05:23:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728340AbgABNWW (ORCPT + 99 others); Thu, 2 Jan 2020 08:22:22 -0500 Received: from foss.arm.com ([217.140.110.172]:47148 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728298AbgABNWW (ORCPT ); Thu, 2 Jan 2020 08:22:22 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 437CF1FB; Thu, 2 Jan 2020 05:22:21 -0800 (PST) Received: from [10.1.194.46] (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5C13C3F703; Thu, 2 Jan 2020 05:22:20 -0800 (PST) Subject: Re: [PATCH] cpu-topology: warn if NUMA configurations conflicts with lower layer To: "Zengtao (B)" , Sudeep Holla Cc: Linuxarm , Greg Kroah-Hartman , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Morten Rasmussen References: <1577088979-8545-1-git-send-email-prime.zeng@hisilicon.com> <20191231164051.GA4864@bogus> <678F3D1BB717D949B966B68EAEB446ED340AE1D3@dggemm526-mbx.china.huawei.com> <20200102112955.GC4864@bogus> <678F3D1BB717D949B966B68EAEB446ED340AEB67@dggemm526-mbx.china.huawei.com> From: Valentin Schneider Message-ID: Date: Thu, 2 Jan 2020 13:22:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED340AEB67@dggemm526-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/01/2020 12:47, Zengtao (B) wrote: >> >> As I said, wrong configurations need to be detected when generating >> DT/ACPI if possible. The above will print warning on systems with NUMA >> within package. >> >> NUMA: 0-7, 8-15 >> core_siblings: 0-15 >> >> The above is the example where the die has 16 CPUs and 2 NUMA nodes >> within a package, your change throws error to the above config which is >> wrong. >> > From your example, the core 7 and core 8 has got different LLC but the same Low > Level cache? AFAIA what matters here is memory controllers, less so LLCs. Cores within a single die could have private LLCs and separate memory controllers, or shared LLC and separate memory controllers. > From schedule view of point, lower level sched domain should be a subset of higher > Level sched domain. > Right, and that is checked when you have sched_debug on the cmdline (or write 1 to /sys/kernel/debug/sched_debug & regenerate the sched domains) Now, I don't know how this plays out for the numa-in-package topologies like the one suggested by Sudeep. x86 and AMD had to play some games to get numa-in-package topologies working, see e.g. cebf15eb09a2 ("x86, sched: Add new topology for multi-NUMA-node CPUs") perhaps you need to "lie" here and ensure sub-NUMA sched domain levels are a subset of the NUMA levels, i.e. lie for core_siblings. I might go and play with this to see how it behaves.