From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Linton Subject: Re: [PATCH 1/4] ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens Date: Thu, 28 Mar 2019 10:20:49 -0500 Message-ID: <7b1a15e4-3d16-4c39-542b-f86a4451a592@arm.com> References: <20190326223938.5365-1-jeremy.linton@arm.com> <20190326223938.5365-2-jeremy.linton@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: "Rafael J. Wysocki" Cc: Linux ARM , ACPI Devel Maling List , Linux Kernel Mailing List , Catalin Marinas , Will Deacon , "Rafael J. Wysocki" , Len Brown , Mark Rutland , Sudeep Holla , James Morse , Lorenzo Pieralisi , Linuxarm List-Id: linux-acpi@vger.kernel.org Hi, First, thanks for taking a look at this. On 3/28/19 5:04 AM, Rafael J. Wysocki wrote: > On Tue, Mar 26, 2019 at 11:40 PM Jeremy Linton wrote: >> >> ACPI 6.3 adds a flag to indicate that child nodes are all >> identical cores. This is useful to authoritatively determine >> if a set of (possibly offline) cores are identical or not. >> >> Since the flag doesn't give us a unique id we can generate >> one and use it to create bitmaps of sibling nodes, or simply >> in a loop to determine if a subset of cores are identical. >> >> Signed-off-by: Jeremy Linton >> --- >> drivers/acpi/pptt.c | 26 ++++++++++++++++++++++++++ >> include/linux/acpi.h | 5 +++++ >> 2 files changed, 31 insertions(+) >> >> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c >> index 065c4fc245d1..472c95ec816b 100644 >> --- a/drivers/acpi/pptt.c >> +++ b/drivers/acpi/pptt.c >> @@ -660,3 +660,29 @@ int find_acpi_cpu_topology_package(unsigned int cpu) >> return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE, >> ACPI_PPTT_PHYSICAL_PACKAGE); >> } >> + >> +/** >> + * find_acpi_cpu_topology_hetero_id() - Determine a unique implementation > > Maybe "Get a core architecture tag"? Sure. > >> + * @cpu: Kernel logical cpu number > > s/logical cpu/logical CPU/ please. Sure. > >> + * >> + * Determine a unique heterogeneous ID for the given CPU. CPUs with the same >> + * implementation should have matching IDs. Since this is a tree we can only >> + * detect implementations where the heterogeneous flag is the parent to all >> + * matching cores. AKA if a two socket machine has two different core types >> + * in each socket this will end up being represented as four unique core types >> + * rather than two. > > I find it quite difficult to parse that comment, honestly. > > AFAICS, the function returns a tag that will be the same for all cores > with the same architecture in one package. That is, if the package is > heterogeneous and there are two types of cores in it, there will be > two different tags. Is this correct? Yes, two ID/tags per package, but since there are two packages (in this example) its four different tags total. This is forced by the need to have a node with the PACKAGE flag set splitting up IDENTICAL cores within the tree. A simpler topology would hopefully be able to group all the identical cores in the machine together. But in the above case using only the PPTT tree, it may not be possible to authoritatively tell how many different core types are in the machine if there are more than two tag groupings. By itself those four tags in the above example may be four different core types, or only two. That is likely not a huge problem as a processor container, or MIDR, can be used to merge different tag groups together depending on the callers needs. > >> + * >> + * The returned ID can be used to group peers with identical implementation. >> + * >> + * The search terminates when a level is found with the identical implementation >> + * flag set or we reach a root node. >> + * >> + * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. >> + * Otherwise returns a value which represents a group of identical cores >> + * similar to this cpu. >> + */ >> +int find_acpi_cpu_topology_hetero_id(unsigned int cpu) >> +{ >> + return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE, >> + ACPI_PPTT_ACPI_IDENTICAL); >> +} >> diff --git a/include/linux/acpi.h b/include/linux/acpi.h >> index d5dcebd7aad3..1444fb042898 100644 >> --- a/include/linux/acpi.h >> +++ b/include/linux/acpi.h >> @@ -1309,6 +1309,7 @@ static inline int lpit_read_residency_count_address(u64 *address) >> #ifdef CONFIG_ACPI_PPTT >> int find_acpi_cpu_topology(unsigned int cpu, int level); >> int find_acpi_cpu_topology_package(unsigned int cpu); >> +int find_acpi_cpu_topology_hetero_id(unsigned int cpu); >> int find_acpi_cpu_cache_topology(unsigned int cpu, int level); >> #else >> static inline int find_acpi_cpu_topology(unsigned int cpu, int level) >> @@ -1319,6 +1320,10 @@ static inline int find_acpi_cpu_topology_package(unsigned int cpu) >> { >> return -EINVAL; >> } >> +static int find_acpi_cpu_topology_hetero_id(unsigned int cpu) >> +{ >> + return -EINVAL; >> +} >> static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level) >> { >> return -EINVAL; >> -- >> 2.20.1 >> 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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C0A0C43381 for ; Thu, 28 Mar 2019 15:21:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4B34420823 for ; Thu, 28 Mar 2019 15:21:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZGvCO80m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B34420823 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=K+qxpTRzr0UUK87gIpoubyHDJ0wgAYPMRjKTgqrw5vQ=; b=ZGvCO80m6oHq+JGyws/SRsV+c spJI/cUJd5Oen9HSyHaiEPASb/nD6PsNvr9rriQX7PaI0ACJ255WB+RF9VcjVlgSYs+U5opMMJyPU dWlm9kMIfkRvixrlPPOhsqEVbtlTb3yifTma047eBHUwrdSU0DNHJk4KQfYzMwUCFSmo+sGhIlS1x 4crgxapwZBreU81R/B3CfKoNRc5C6Cs0yZQzFv3BEK7TCt7a9YNUVAmToXNNE/qSiEV95uO9lq+UO 8u3gScQpJRbsWML0RlhHRKfyDnB6QNEobJTTnpAjgxG92MBKr7Q92nC/hj0c+EKiE3A12Ft/a/u+B YIsSmyMFA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9Wpz-0002ka-OF; Thu, 28 Mar 2019 15:21:03 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9Wpw-0002jv-Gv for linux-arm-kernel@lists.infradead.org; Thu, 28 Mar 2019 15:21:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 74AB115AB; Thu, 28 Mar 2019 08:20:57 -0700 (PDT) Received: from [192.168.100.242] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 643EA3F557; Thu, 28 Mar 2019 08:20:56 -0700 (PDT) Subject: Re: [PATCH 1/4] ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens To: "Rafael J. Wysocki" References: <20190326223938.5365-1-jeremy.linton@arm.com> <20190326223938.5365-2-jeremy.linton@arm.com> From: Jeremy Linton Message-ID: <7b1a15e4-3d16-4c39-542b-f86a4451a592@arm.com> Date: Thu, 28 Mar 2019 10:20:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190328_082100_572124_9909914F X-CRM114-Status: GOOD ( 25.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Lorenzo Pieralisi , Will Deacon , Sudeep Holla , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linuxarm , ACPI Devel Maling List , James Morse , Catalin Marinas , Linux ARM , Len Brown Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, First, thanks for taking a look at this. On 3/28/19 5:04 AM, Rafael J. Wysocki wrote: > On Tue, Mar 26, 2019 at 11:40 PM Jeremy Linton wrote: >> >> ACPI 6.3 adds a flag to indicate that child nodes are all >> identical cores. This is useful to authoritatively determine >> if a set of (possibly offline) cores are identical or not. >> >> Since the flag doesn't give us a unique id we can generate >> one and use it to create bitmaps of sibling nodes, or simply >> in a loop to determine if a subset of cores are identical. >> >> Signed-off-by: Jeremy Linton >> --- >> drivers/acpi/pptt.c | 26 ++++++++++++++++++++++++++ >> include/linux/acpi.h | 5 +++++ >> 2 files changed, 31 insertions(+) >> >> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c >> index 065c4fc245d1..472c95ec816b 100644 >> --- a/drivers/acpi/pptt.c >> +++ b/drivers/acpi/pptt.c >> @@ -660,3 +660,29 @@ int find_acpi_cpu_topology_package(unsigned int cpu) >> return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE, >> ACPI_PPTT_PHYSICAL_PACKAGE); >> } >> + >> +/** >> + * find_acpi_cpu_topology_hetero_id() - Determine a unique implementation > > Maybe "Get a core architecture tag"? Sure. > >> + * @cpu: Kernel logical cpu number > > s/logical cpu/logical CPU/ please. Sure. > >> + * >> + * Determine a unique heterogeneous ID for the given CPU. CPUs with the same >> + * implementation should have matching IDs. Since this is a tree we can only >> + * detect implementations where the heterogeneous flag is the parent to all >> + * matching cores. AKA if a two socket machine has two different core types >> + * in each socket this will end up being represented as four unique core types >> + * rather than two. > > I find it quite difficult to parse that comment, honestly. > > AFAICS, the function returns a tag that will be the same for all cores > with the same architecture in one package. That is, if the package is > heterogeneous and there are two types of cores in it, there will be > two different tags. Is this correct? Yes, two ID/tags per package, but since there are two packages (in this example) its four different tags total. This is forced by the need to have a node with the PACKAGE flag set splitting up IDENTICAL cores within the tree. A simpler topology would hopefully be able to group all the identical cores in the machine together. But in the above case using only the PPTT tree, it may not be possible to authoritatively tell how many different core types are in the machine if there are more than two tag groupings. By itself those four tags in the above example may be four different core types, or only two. That is likely not a huge problem as a processor container, or MIDR, can be used to merge different tag groups together depending on the callers needs. > >> + * >> + * The returned ID can be used to group peers with identical implementation. >> + * >> + * The search terminates when a level is found with the identical implementation >> + * flag set or we reach a root node. >> + * >> + * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. >> + * Otherwise returns a value which represents a group of identical cores >> + * similar to this cpu. >> + */ >> +int find_acpi_cpu_topology_hetero_id(unsigned int cpu) >> +{ >> + return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE, >> + ACPI_PPTT_ACPI_IDENTICAL); >> +} >> diff --git a/include/linux/acpi.h b/include/linux/acpi.h >> index d5dcebd7aad3..1444fb042898 100644 >> --- a/include/linux/acpi.h >> +++ b/include/linux/acpi.h >> @@ -1309,6 +1309,7 @@ static inline int lpit_read_residency_count_address(u64 *address) >> #ifdef CONFIG_ACPI_PPTT >> int find_acpi_cpu_topology(unsigned int cpu, int level); >> int find_acpi_cpu_topology_package(unsigned int cpu); >> +int find_acpi_cpu_topology_hetero_id(unsigned int cpu); >> int find_acpi_cpu_cache_topology(unsigned int cpu, int level); >> #else >> static inline int find_acpi_cpu_topology(unsigned int cpu, int level) >> @@ -1319,6 +1320,10 @@ static inline int find_acpi_cpu_topology_package(unsigned int cpu) >> { >> return -EINVAL; >> } >> +static int find_acpi_cpu_topology_hetero_id(unsigned int cpu) >> +{ >> + return -EINVAL; >> +} >> static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level) >> { >> return -EINVAL; >> -- >> 2.20.1 >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel