From patchwork Thu Sep 22 13:37:53 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985121 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 867CEC6FA82 for ; Thu, 22 Sep 2022 13:35:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231487AbiIVNfE (ORCPT ); Thu, 22 Sep 2022 09:35:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231516AbiIVNfC (ORCPT ); Thu, 22 Sep 2022 09:35:02 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27E76760EF; Thu, 22 Sep 2022 06:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853702; x=1695389702; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=zDRjOn0bNlzHygZ+Y/AQDCZ7jTp+MJset84jKlggh44=; b=Dig47Rh4igi2ufHozJ8YRt3f2k0xH4mskSCW/Bz4aL4udRGT5mL5h+oY 5prF5pTDzMZvLQyBKFzcNsEt2Ey3LpoAwqrMwHRWeA277e7ZKQzAv5YN9 K+Yh+nnuGk0MsRESF86NtYv36/mr7eHuYcqKlrZ8SCZwkin4P3fiiy7uM 0RJXKLA3M4LkOsMonSj2UT7myNJpMIw8cMqLwGDzKtVf6WpHqovVZnpc+ M1N4BbOemzDbhRpuKK1VxuwZ7RGmsMJjSnu3n1rozvFFKtRUvIOCMU9En TrpLfEMSjY1AQ7YOT+DdiMlhYBDgHRZMb3BgdplOzOrPL27uvoaSvduow A==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894097" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894097" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793823" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:34:57 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 1/8] perf/x86/intel/P4: Unify logic for detecting HT Date: Thu, 22 Sep 2022 21:37:53 +0800 Message-Id: <20220922133800.12918-2-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org Any value larger than 1 suggests HT is supported. Although smp_num_siblings cannot be larger than 2 on P4 platform, it is better to keep the logic consistent across the kernel. Reviewed-by: Len Brown Signed-off-by: Zhang Rui --- arch/x86/include/asm/perf_event_p4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/perf_event_p4.h b/arch/x86/include/asm/perf_event_p4.h index 94de1a05aeba..b14e9a20a7c0 100644 --- a/arch/x86/include/asm/perf_event_p4.h +++ b/arch/x86/include/asm/perf_event_p4.h @@ -189,7 +189,7 @@ static inline int p4_ht_active(void) static inline int p4_ht_thread(int cpu) { #ifdef CONFIG_SMP - if (smp_num_siblings == 2) + if (smp_num_siblings > 1) return cpu != cpumask_first(this_cpu_cpumask_var_ptr(cpu_sibling_map)); #endif return 0; From patchwork Thu Sep 22 13:37:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985122 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86333C6FA82 for ; Thu, 22 Sep 2022 13:35:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231630AbiIVNfV (ORCPT ); Thu, 22 Sep 2022 09:35:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231408AbiIVNfQ (ORCPT ); Thu, 22 Sep 2022 09:35:16 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23F827F0AB; Thu, 22 Sep 2022 06:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853706; x=1695389706; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=uNmyJGFQ0sIPiZsSeZdd651qCRfEeR1fmTyxguCl9bY=; b=EHzMk5BPyj9Tb1F8IhQa8puZ8fku4FXpiV6L3GbZUa7v1RfgZm2+hNiy HKHweYHXrI0v3baxkSq/ogJ8IBGijsHTODFujpxsoVt37FHvJUFS3+i0H iDunwdr06up1yOaOjfpgTf2PYgg7sxpO9Oq1dkRBgdaAV+oyj2wkenITB 1l9r04B5IN5CYxyATfkSzzmM64RVjaipPR+FApG6LxzJt1yQ6xPG3qD5I 2FfjhtxxUQnzYuMb574NwbyIvOnoJlfT6SbfPaLLKnD8NQ4Ryi7WrHuRT /6X543KswGL6LwNN+ifENfU8t40Ms6gm6pR/ygWsEuXGyg3Kev9G2mHy8 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894114" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894114" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793850" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:01 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 2/8] hwmon/coretemp: Rename indx to index Date: Thu, 22 Sep 2022 21:37:54 +0800 Message-Id: <20220922133800.12918-3-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org Use variable name 'index' instead of 'indx' for the index in the core_data[] array. Suggested-by: Ingo Molnar Signed-off-by: Zhang Rui Acked-by: Guenter Roeck --- drivers/hwmon/coretemp.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c index ccf0af5b988a..bfdcfe8ccb34 100644 --- a/drivers/hwmon/coretemp.c +++ b/drivers/hwmon/coretemp.c @@ -515,15 +515,15 @@ coretemp_add_core(struct platform_device *pdev, unsigned int cpu, int pkg_flag) dev_err(&pdev->dev, "Adding Core %u failed\n", cpu); } -static void coretemp_remove_core(struct platform_data *pdata, int indx) +static void coretemp_remove_core(struct platform_data *pdata, int index) { - struct temp_data *tdata = pdata->core_data[indx]; + struct temp_data *tdata = pdata->core_data[index]; /* Remove the sysfs attributes */ sysfs_remove_group(&pdata->hwmon_dev->kobj, &tdata->attr_group); - kfree(pdata->core_data[indx]); - pdata->core_data[indx] = NULL; + kfree(pdata->core_data[index]); + pdata->core_data[index] = NULL; } static int coretemp_probe(struct platform_device *pdev) @@ -647,7 +647,7 @@ static int coretemp_cpu_offline(unsigned int cpu) struct platform_device *pdev = coretemp_get_pdev(cpu); struct platform_data *pd; struct temp_data *tdata; - int indx, target; + int index, target; /* * Don't execute this on suspend as the device remove locks @@ -661,12 +661,12 @@ static int coretemp_cpu_offline(unsigned int cpu) return 0; /* The core id is too big, just return */ - indx = TO_ATTR_NO(cpu); - if (indx > MAX_CORE_DATA - 1) + index = TO_ATTR_NO(cpu); + if (index > MAX_CORE_DATA - 1) return 0; pd = platform_get_drvdata(pdev); - tdata = pd->core_data[indx]; + tdata = pd->core_data[index]; cpumask_clear_cpu(cpu, &pd->cpumask); @@ -677,7 +677,7 @@ static int coretemp_cpu_offline(unsigned int cpu) */ target = cpumask_any_and(&pd->cpumask, topology_sibling_cpumask(cpu)); if (target >= nr_cpu_ids) { - coretemp_remove_core(pd, indx); + coretemp_remove_core(pd, index); } else if (tdata && tdata->cpu == cpu) { mutex_lock(&tdata->update_lock); tdata->cpu = target; From patchwork Thu Sep 22 13:37:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985123 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 420F6C6FA86 for ; Thu, 22 Sep 2022 13:35:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231580AbiIVNfY (ORCPT ); Thu, 22 Sep 2022 09:35:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231574AbiIVNfT (ORCPT ); Thu, 22 Sep 2022 09:35:19 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E4DE87086; Thu, 22 Sep 2022 06:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853710; x=1695389710; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=izKx2i2YnCzZigJqPxNJZEiqz/oZMoOAlgtG1yN62lw=; b=PohLzI8KXtS8aX/xNh0RTpCAfdiQ4l5r3Q5tn5CLEfTLxLtigExxHJH7 OuiUnWIgerui+TVN0zKld8pEJ2xp7KAzGWdq9sV5ItnFWHHXDtkRtszdA ZZ8ux94UUwnlFwpMoGuw1r0axjXx78jB0YlZK0K4GzcC0PU4QefG0YXod nFT4VKvsQ62gA63D2wE2yfxVz9oh0OiQmElAqPrE9/kMj7Fpzw7JRUp8o Wfi8tRUZ88u/xeJL2igk4D9G2QRbFIg4GqptW3diou05pkXqByFz7FXaU UmGJ95wIi3Nx6eMw+vqnF3H+PA2ANfpJq7S5fS8326520xJNvEHYV9NSo g==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894128" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894128" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793884" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:05 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 3/8] hwmon/coretemp: Handle large core ID value Date: Thu, 22 Sep 2022 21:37:55 +0800 Message-Id: <20220922133800.12918-4-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org The coretemp driver supports up to a hard-coded limit of 128 cores. Today, the driver can not support a core with an ID above that limit. Yet, the encoding of core ID's is arbitrary (BIOS APIC-ID) and so they may be sparse and they may be large. Update the driver to map arbitrary core ID numbers into appropriate array indexes so that 128 cores can be supported, no matter the encoding of core ID's. Acked-by: Len Brown Signed-off-by: Zhang Rui Acked-by: Guenter Roeck --- drivers/hwmon/coretemp.c | 56 +++++++++++++++++++++++++++++----------- 1 file changed, 41 insertions(+), 15 deletions(-) diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c index bfdcfe8ccb34..291566aeb703 100644 --- a/drivers/hwmon/coretemp.c +++ b/drivers/hwmon/coretemp.c @@ -46,9 +46,6 @@ MODULE_PARM_DESC(tjmax, "TjMax value in degrees Celsius"); #define TOTAL_ATTRS (MAX_CORE_ATTRS + 1) #define MAX_CORE_DATA (NUM_REAL_CORES + BASE_SYSFS_ATTR_NO) -#define TO_CORE_ID(cpu) (cpu_data(cpu).cpu_core_id) -#define TO_ATTR_NO(cpu) (TO_CORE_ID(cpu) + BASE_SYSFS_ATTR_NO) - #ifdef CONFIG_SMP #define for_each_sibling(i, cpu) \ for_each_cpu(i, topology_sibling_cpumask(cpu)) @@ -91,6 +88,8 @@ struct temp_data { struct platform_data { struct device *hwmon_dev; u16 pkg_id; + u16 cpu_map[NUM_REAL_CORES]; + struct ida ida; struct cpumask cpumask; struct temp_data *core_data[MAX_CORE_DATA]; struct device_attribute name_attr; @@ -441,7 +440,7 @@ static struct temp_data *init_temp_data(unsigned int cpu, int pkg_flag) MSR_IA32_THERM_STATUS; tdata->is_pkg_data = pkg_flag; tdata->cpu = cpu; - tdata->cpu_core_id = TO_CORE_ID(cpu); + tdata->cpu_core_id = topology_core_id(cpu); tdata->attr_size = MAX_CORE_ATTRS; mutex_init(&tdata->update_lock); return tdata; @@ -454,7 +453,7 @@ static int create_core_data(struct platform_device *pdev, unsigned int cpu, struct platform_data *pdata = platform_get_drvdata(pdev); struct cpuinfo_x86 *c = &cpu_data(cpu); u32 eax, edx; - int err, attr_no; + int err, index, attr_no; /* * Find attr number for sysfs: @@ -462,14 +461,26 @@ static int create_core_data(struct platform_device *pdev, unsigned int cpu, * The attr number is always core id + 2 * The Pkgtemp will always show up as temp1_*, if available */ - attr_no = pkg_flag ? PKG_SYSFS_ATTR_NO : TO_ATTR_NO(cpu); + if (pkg_flag) { + attr_no = PKG_SYSFS_ATTR_NO; + } else { + index = ida_alloc(&pdata->ida, GFP_KERNEL); + if (index < 0) + return index; + pdata->cpu_map[index] = topology_core_id(cpu); + attr_no = index + BASE_SYSFS_ATTR_NO; + } - if (attr_no > MAX_CORE_DATA - 1) - return -ERANGE; + if (attr_no > MAX_CORE_DATA - 1) { + err = -ERANGE; + goto ida_free; + } tdata = init_temp_data(cpu, pkg_flag); - if (!tdata) - return -ENOMEM; + if (!tdata) { + err = -ENOMEM; + goto ida_free; + } /* Test if we can access the status register */ err = rdmsr_safe_on_cpu(cpu, tdata->status_reg, &eax, &edx); @@ -505,6 +516,9 @@ static int create_core_data(struct platform_device *pdev, unsigned int cpu, exit_free: pdata->core_data[attr_no] = NULL; kfree(tdata); +ida_free: + if (!pkg_flag) + ida_free(&pdata->ida, index); return err; } @@ -524,6 +538,9 @@ static void coretemp_remove_core(struct platform_data *pdata, int index) kfree(pdata->core_data[index]); pdata->core_data[index] = NULL; + + if (index >= BASE_SYSFS_ATTR_NO) + ida_free(&pdata->ida, index - BASE_SYSFS_ATTR_NO); } static int coretemp_probe(struct platform_device *pdev) @@ -537,6 +554,7 @@ static int coretemp_probe(struct platform_device *pdev) return -ENOMEM; pdata->pkg_id = pdev->id; + ida_init(&pdata->ida); platform_set_drvdata(pdev, pdata); pdata->hwmon_dev = devm_hwmon_device_register_with_groups(dev, DRVNAME, @@ -553,6 +571,7 @@ static int coretemp_remove(struct platform_device *pdev) if (pdata->core_data[i]) coretemp_remove_core(pdata, i); + ida_destroy(&pdata->ida); return 0; } @@ -647,7 +666,7 @@ static int coretemp_cpu_offline(unsigned int cpu) struct platform_device *pdev = coretemp_get_pdev(cpu); struct platform_data *pd; struct temp_data *tdata; - int index, target; + int i, index = -1, target; /* * Don't execute this on suspend as the device remove locks @@ -660,12 +679,19 @@ static int coretemp_cpu_offline(unsigned int cpu) if (!pdev) return 0; - /* The core id is too big, just return */ - index = TO_ATTR_NO(cpu); - if (index > MAX_CORE_DATA - 1) + pd = platform_get_drvdata(pdev); + + for (i = 0; i < NUM_REAL_CORES; i++) { + if (pd->cpu_map[i] == topology_core_id(cpu)) { + index = i + BASE_SYSFS_ATTR_NO; + break; + } + } + + /* Too many cores and this core is not populated, just return */ + if (index < 0) return 0; - pd = platform_get_drvdata(pdev); tdata = pd->core_data[index]; cpumask_clear_cpu(cpu, &pd->cpumask); From patchwork Thu Sep 22 13:37:56 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985124 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 184F2C6FA82 for ; Thu, 22 Sep 2022 13:35:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231772AbiIVNfe (ORCPT ); Thu, 22 Sep 2022 09:35:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230402AbiIVNfW (ORCPT ); Thu, 22 Sep 2022 09:35:22 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 913EE9083D; Thu, 22 Sep 2022 06:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853713; x=1695389713; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=L/YUk+xorUbS4Lxt2Dw5oHQ5JwRLb2TqEv7MPMrvgHw=; b=d0u002vALH80wLwFPChnldVytLap7xcNQqe7czUHSNs0ED4AeKWsJDwN etc+Ix+UWXFz8mWYvNnnOv9azjtI+txILF2lAQcjetEDFPHmNCOmYv3oq 3E7I2TGQ4md7xeKggzqgfeP9uZ2dmri35KQY+F24IwlRfCUj3o9kR6n1D IQjGsP5U7xV7uNjeOYlzEZ1z+3x9m5nsz3MUWW+JkvS9AP3do+ifAlNeK y0Lmkae03EG3Xnm5XH0UYzF04MgGuGYOORRDOCCFwHSBsEFibZfzNdidi ceoeJMDUBxfP5xFj04yYVHJc5nxC0cTgWoJpsmymausJyiwfjWMx+TPaj A==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894140" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894140" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793927" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:09 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 4/8] x86/topology: Fix multiple packages shown on a single-package system Date: Thu, 22 Sep 2022 21:37:56 +0800 Message-Id: <20220922133800.12918-5-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org CPUID.1F/B does not emumerate Package level explicitly, instead, all the APIC-ID bits above the enumerated levels are assumed to be package ID bits. Current code gets package ID by shifting out all the APIC-ID bits that Linux supports, rather than shifting out all the APIC-ID bits that CPUID.1F enumerates. This introduces problems when CPUID.1F enumerates a level that Linux does not support. For example, on an AlderLake-N platform, there are 2 Ecore Modules, which has 4 atom cores in each module, in a single package. Linux does not support Module level and interprets the Module ID bits as package ID and erroneously reports a multi module system as a multi-package system. Fix this by using APIC-ID bits above all the CPUID.1F enumerated levels as package ID. Suggested-by: Len Brown Reviewed-by: Len Brown Signed-off-by: Zhang Rui --- arch/x86/kernel/cpu/topology.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 132a2de44d2f..f7592814e5d5 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -96,6 +96,7 @@ int detect_extended_topology(struct cpuinfo_x86 *c) unsigned int ht_mask_width, core_plus_mask_width, die_plus_mask_width; unsigned int core_select_mask, core_level_siblings; unsigned int die_select_mask, die_level_siblings; + unsigned int pkg_mask_width; bool die_level_present = false; int leaf; @@ -111,10 +112,10 @@ int detect_extended_topology(struct cpuinfo_x86 *c) core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx); core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); die_level_siblings = LEVEL_MAX_SIBLINGS(ebx); - die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); + pkg_mask_width = die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); sub_index = 1; - do { + while (true) { cpuid_count(leaf, sub_index, &eax, &ebx, &ecx, &edx); /* @@ -132,8 +133,13 @@ int detect_extended_topology(struct cpuinfo_x86 *c) die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); } + if (LEAFB_SUBTYPE(ecx) != INVALID_TYPE) + pkg_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); + else + break; + sub_index++; - } while (LEAFB_SUBTYPE(ecx) != INVALID_TYPE); + } core_select_mask = (~(-1 << core_plus_mask_width)) >> ht_mask_width; die_select_mask = (~(-1 << die_plus_mask_width)) >> @@ -148,7 +154,7 @@ int detect_extended_topology(struct cpuinfo_x86 *c) } c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, - die_plus_mask_width); + pkg_mask_width); /* * Reinit the apicid, now that we have extended initial_apicid. */ From patchwork Thu Sep 22 13:37:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985125 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AE6CC54EE9 for ; Thu, 22 Sep 2022 13:35:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231408AbiIVNfk (ORCPT ); Thu, 22 Sep 2022 09:35:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231615AbiIVNfY (ORCPT ); Thu, 22 Sep 2022 09:35:24 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92ACB98CAE; Thu, 22 Sep 2022 06:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853717; x=1695389717; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=kbVKhVENfs1ZKJPfvDDpV0tOaAWB+7OvnBODgaAPd6s=; b=jilbV74ft9wO06qlr+3GGgxm/15Ins4bLUBYt1mIQVK0Vt+MpFMZN0SF 6Ncx7twLFn6KorC4EyC3/V5lpLBGld++4VBOK8gvh8LT+NsfAOKh+d+55 kdtPxweazQ73Kn2jzD+CfXIfwD+9Cfxv744lStRpYE+s3fLvgEoi1tQr0 tks90bEbevgJREhenyO/UJdxBoZwOyRJSSM+DIjeWxX2pZ7HWwrjrmYwn DwVKskqLKWvMHDv45tA7jHbu2HA8+coA/amAWOgka2r6yywrP19m2g93e LgrOSvSjoWUTfpSFF4husulSavtoDPQf7S8QYMrPygJGnt7ikuhx7Xi4J A==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894152" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894152" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793944" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:13 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 5/8] x86/topology: Fix duplicated core ID within a package Date: Thu, 22 Sep 2022 21:37:57 +0800 Message-Id: <20220922133800.12918-6-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org Today, core ID is assumed to be unique within each package. But an AlderLake-N platform adds a Module level between core and package, Linux excludes the unknown modules bits from the core ID, resulting in duplicate core ID's. To keep core ID unique within a package, Linux must include all APIC-ID bits for known or un-known levels above the core and below the package in the core ID. It is important to understand that core ID's have always come directly from the APIC-ID encoding, which comes from the BIOS. Thus there is no guarantee that they start at 0, or that they are contiguous. As such, naively using them for array indexes can be problematic. Suggested-by: Len Brown Reviewed-by: Len Brown Signed-off-by: Zhang Rui --- arch/x86/kernel/cpu/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index f7592814e5d5..5e868b62a7c4 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -141,7 +141,7 @@ int detect_extended_topology(struct cpuinfo_x86 *c) sub_index++; } - core_select_mask = (~(-1 << core_plus_mask_width)) >> ht_mask_width; + core_select_mask = (~(-1 << pkg_mask_width)) >> ht_mask_width; die_select_mask = (~(-1 << die_plus_mask_width)) >> core_plus_mask_width; From patchwork Thu Sep 22 13:37:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985126 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DAA19C6FA82 for ; Thu, 22 Sep 2022 13:36:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231377AbiIVNgB (ORCPT ); Thu, 22 Sep 2022 09:36:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231622AbiIVNf3 (ORCPT ); Thu, 22 Sep 2022 09:35:29 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34D78816B4; Thu, 22 Sep 2022 06:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853721; x=1695389721; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=2OhBnvE4h3ElR/24O980M3qGJSzPy56Nnkjhkgl85Ys=; b=GqSPXbHAZv5se+rNRhwbRgWUthb6AihUceM6ZvStXuJRA5vZgeFvYgn3 59oWqqy5HfyFxGwuTy8z0p93OFmscc/Wi3LXxjtqUzMqMQ80d0J3jq8PW OCoTfEYvnGeuvtXOZI+deIhF8ZHsYKRuRQOfOH54KSsNVz4W5uCHfV88I pwqWLrrBvVugP0IuCc1ssrHE2t23kDRkpJSDrz46rdaLskLALEMd+O+48 WXHnRUck3JxJKQTI/ylPC3Jda01QHzRnixBtRmIpys+RaesXUpZdum+Yh Wih0k21TUU4pP08RqgMTe3qiAwETdV62A8/WGuOnjB/762y6SPlbnw6ps w==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894160" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894160" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793962" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:17 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 6/8] x86/topology: Fix max_siblings calculation Date: Thu, 22 Sep 2022 21:37:58 +0800 Message-Id: <20220922133800.12918-7-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org The max siblings value returned by CPUID.1F SMT level EBX differs among CPUs on Intel Hybrid platforms like ADL-S/P. It returns 2 for Pcore CPUs which have HT sibling and 1 for Ecore CPUs which do not. Today, CPUID SMT level EBX sets the global variable smp_num_siblings. Thus, smp_num_siblings is overridden to different values based on the CPU Pcore/Ecore enumeration order. For example, [ 0.201005] detect_extended_topology: CPU APICID 0x0, smp_num_siblings 2, x86_max_cores 10 [ 0.201117] start_kernel->check_bugs->cpu_smt_check_topology: smp_num_siblings 2 ... [ 0.010146] detect_extended_topology: CPU APICID 0x8, smp_num_siblings 2, x86_max_cores 10 ... [ 0.010146] detect_extended_topology: CPU APICID 0x39, smp_num_siblings 2, x86_max_cores 10 [ 0.010146] detect_extended_topology: CPU APICID 0x48, smp_num_siblings 1, x86_max_cores 20 ... [ 0.010146] detect_extended_topology: CPU APICID 0x4e, smp_num_siblings 1, x86_max_cores 20 [ 2.583800] sched_set_itmt_core_prio: smp_num_siblings 1 This inconsistency brings several potential issues: 1. some kernel configuration like cpu_smt_control, as set in start_kernel()->check_bugs()->cpu_smt_check_topology(), depends on smp_num_siblings set by cpu0. It is pure luck that all the current hybrid platforms use Pcore as cpu0 and hide this problem. 2. some per CPU data like cpuinfo_x86.x86_max_cores that depends on smp_num_siblings becomes inconsistent and bogus. 3. the final smp_num_siblings value after boot depends on the last CPU enumerated, which could either be Pcore or Ecore CPU. The solution is to use CPUID EAX bits_shift to get the maximum number of addressable logical processors, and use this to determin max siblings. Because: 1. the CPUID EAX bits_shift values are consistent among CPUs as far as observed. 2. some code already uses smp_num_siblings value to isolate the SMT ID bits in APIC-ID, like apic_id_is_primary_thread(). Suggested-by: Len Brown Reviewed-by: Len Brown Signed-off-by: Zhang Rui --- arch/x86/kernel/cpu/topology.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 5e868b62a7c4..2a88f2fa5756 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -23,7 +23,12 @@ #define LEAFB_SUBTYPE(ecx) (((ecx) >> 8) & 0xff) #define BITS_SHIFT_NEXT_LEVEL(eax) ((eax) & 0x1f) -#define LEVEL_MAX_SIBLINGS(ebx) ((ebx) & 0xffff) + +/* + * Use EAX bit_shift to calculate the maximum number of addressable logical + * processors sharing the current level. + */ +#define LEVEL_MAX_SIBLINGS(eax) (1 << BITS_SHIFT_NEXT_LEVEL(eax)) unsigned int __max_die_per_package __read_mostly = 1; EXPORT_SYMBOL(__max_die_per_package); @@ -79,7 +84,7 @@ int detect_extended_topology_early(struct cpuinfo_x86 *c) * initial apic id, which also represents 32-bit extended x2apic id. */ c->initial_apicid = edx; - smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx); + smp_num_siblings = LEVEL_MAX_SIBLINGS(eax); #endif return 0; } @@ -109,9 +114,9 @@ int detect_extended_topology(struct cpuinfo_x86 *c) */ cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx); c->initial_apicid = edx; - core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx); + core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(eax); core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); - die_level_siblings = LEVEL_MAX_SIBLINGS(ebx); + die_level_siblings = LEVEL_MAX_SIBLINGS(eax); pkg_mask_width = die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); sub_index = 1; @@ -122,14 +127,14 @@ int detect_extended_topology(struct cpuinfo_x86 *c) * Check for the Core type in the implemented sub leaves. */ if (LEAFB_SUBTYPE(ecx) == CORE_TYPE) { - core_level_siblings = LEVEL_MAX_SIBLINGS(ebx); + core_level_siblings = LEVEL_MAX_SIBLINGS(eax); core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); die_level_siblings = core_level_siblings; die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); } if (LEAFB_SUBTYPE(ecx) == DIE_TYPE) { die_level_present = true; - die_level_siblings = LEVEL_MAX_SIBLINGS(ebx); + die_level_siblings = LEVEL_MAX_SIBLINGS(eax); die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); } From patchwork Thu Sep 22 13:37:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985127 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AC01C54EE9 for ; Thu, 22 Sep 2022 13:36:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231597AbiIVNgE (ORCPT ); Thu, 22 Sep 2022 09:36:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231739AbiIVNfb (ORCPT ); Thu, 22 Sep 2022 09:35:31 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07532895CB; Thu, 22 Sep 2022 06:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853725; x=1695389725; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=u+ZvcOj9M2zkdP1mQyjcoYw0fYKI0r1gp+/88xhN1yA=; b=DkPDakjyJhGqFM05ZMmsRnLo1BgDFvex/U4IWdQKVEIAVRVu1VbIbX9G BLA+ZApXPfsMuJUlw1qIMg1L/JM39GqHIJQf5DVfAwRr4eqOQcG/JE+AK r2I8MoaGe8uxf89SbEvus5hnNAAk+8Qi4NM7G5tDz9Su/P4QV803kkXZy 8Em/+njHwU7n9l8fe4hcAMBVwoV9mGO8ERVr/NH+S2oQ82tLn8uqWgZrg OPW7FaBu3O2lJ6SjH38OmOpnI+J328Yl0tibJPxqnReG6F2GWZ3QBTpLS gvTkK2NrEHXVCZxWtIkmnXzVMS7FdiUBL0Q35mxPv53dNe6TJbmyJ11Ic g==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894170" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894170" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793972" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:21 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 7/8] Documentation: x86: Update smp_num_siblings/x86_max_cores description Date: Thu, 22 Sep 2022 21:37:59 +0800 Message-Id: <20220922133800.12918-8-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org smp_num_siblings/cpuinfo_x86.x86_max_cores are retrieved via CPUID EAX bit_shift value, and they represent the maximum possible number of threads in a core, and the maximum possible number of cores in a package. Update the smp_num_siblings/cpuinfo_x86.x86_max_cores description in the documentation. Reviewed-by: Len Brown Signed-off-by: Zhang Rui --- Documentation/x86/topology.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/x86/topology.rst b/Documentation/x86/topology.rst index 7f58010ea86a..c5eb5bc42380 100644 --- a/Documentation/x86/topology.rst +++ b/Documentation/x86/topology.rst @@ -49,7 +49,8 @@ AMD nomenclature for package is 'Node'. - cpuinfo_x86.x86_max_cores: - The number of cores in a package. This information is retrieved via CPUID. + The maximum possible number of cores in a package. This information is + retrieved via CPUID. - cpuinfo_x86.x86_max_dies: @@ -102,10 +103,10 @@ AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses - smp_num_siblings: - The number of threads in a core. The number of threads in a package can be - calculated by:: + The maximum possible number of threads in a core. The maximum possible + number of threads in a package can be calculated by:: - threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings + maximum_threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings Threads From patchwork Thu Sep 22 13:38:00 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Rui X-Patchwork-Id: 12985128 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 472FBC6FA82 for ; Thu, 22 Sep 2022 13:36:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231655AbiIVNgS (ORCPT ); Thu, 22 Sep 2022 09:36:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231775AbiIVNfh (ORCPT ); Thu, 22 Sep 2022 09:35:37 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E046A063C; Thu, 22 Sep 2022 06:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663853731; x=1695389731; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=hbLNyRcLgu/3RSFiCT5I9SBJfhTGwgIQFfI74KmSZMA=; b=eLPPdpkl/aoWd5tG7LHeHfEc4m+RCCG2xmA7m/ReK6FZMtI1FRTmu6Lq EKQztVxPzeEaD2r8hxEffjvj37MFjzvdvC69NSi6OggKm3ruU3H1Pdt3q 8tVm+lBUCV8Oj7AAAqYfxJ+tPNm+IK3nr8hCRF0Jmz0wVFk+soDbbMwb2 uhCwmFae30tcohVlWm5qh1fYeCksqPYn4yC6yUqMdWVS88r6m9Vk2Y3mW rks2DGzmIeehXv5m70uvTwNhmlEJecE3kG8pGzaucVGEhYjSfywKoQgfX CWA9tusVXbL1Gz2koktkgqHBSkO44E3nZKstG8fXyZHtfg7ZJhJHgguRT Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10478"; a="297894189" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="297894189" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 06:35:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="619793984" Received: from power-sh.sh.intel.com ([10.239.183.122]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2022 06:35:24 -0700 From: Zhang Rui To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hwmon@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, corbet@lwn.net, fenghua.yu@intel.com, jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com, rui.zhang@intel.com Subject: [PATCH V3 8/8] Documentation: x86: Remove obsolete x86_max_dies description Date: Thu, 22 Sep 2022 21:38:00 +0800 Message-Id: <20220922133800.12918-9-rui.zhang@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220922133800.12918-1-rui.zhang@intel.com> References: <20220922133800.12918-1-rui.zhang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org cpuinfo_x86.x86_max_dies is introduced in commit 7745f03eb395 ("x86/topology: Add CPUID.1F multi-die/package support") and then removed in commit 14d96d6c06b5 ("x86/topology: Create topology_max_die_per_package()"). Remove the obsolete cpuinfo_x86.x86_max_dies description. Fixes: 14d96d6c06b5 ("x86/topology: Create topology_max_die_per_package()") Reviewed-by: Len Brown Signed-off-by: Zhang Rui --- Documentation/x86/topology.rst | 4 ---- 1 file changed, 4 deletions(-) diff --git a/Documentation/x86/topology.rst b/Documentation/x86/topology.rst index c5eb5bc42380..fbef91b1ee5e 100644 --- a/Documentation/x86/topology.rst +++ b/Documentation/x86/topology.rst @@ -52,10 +52,6 @@ AMD nomenclature for package is 'Node'. The maximum possible number of cores in a package. This information is retrieved via CPUID. - - cpuinfo_x86.x86_max_dies: - - The number of dies in a package. This information is retrieved via CPUID. - - cpuinfo_x86.cpu_die_id: The physical ID of the die. This information is retrieved via CPUID.