Received: by 10.223.185.116 with SMTP id b49csp8901wrg; Thu, 8 Mar 2018 11:58:22 -0800 (PST) X-Google-Smtp-Source: AG47ELsf/DdgrWhegcmGZo1VZ0A3/JDD9YcJjth9eFFtJy5kDxEr6Gir/aNIsvPVjffSEDhUgr/a X-Received: by 2002:a17:902:5303:: with SMTP id b3-v6mr25384082pli.19.1520539102517; Thu, 08 Mar 2018 11:58:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520539102; cv=none; d=google.com; s=arc-20160816; b=ARudZYPN/peNVukTlza4ezwSdyyZw7ixHaSN6fz1u1nvPjKUKxRbXFhXpTJQRdJkX/ lETAD2KS3KV+wCY1vHCvga5XYzQ3WmRQl/VE3lqVst1YfaecmJViHSjetuThOMmrvmIR M0BNC24OdS+ylMPBP1DkhUauiOVbi3sVln8Xxp2DE1l0jkwfv62pXVjcTnbQpttfEIjL 0LiEpJ2eFnJr1BGXva1Q3Hueq3y5QgZfCbL3YufYFO+r5ikatsKON50r0FJK00Y5l976 5LXV/OnkG7uB+4dRF1Ul4pUZ8QLdUYJJLk3oQ8w3i+qOvtIprUimU2WW7xuDysEy2y/6 IysQ== 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:arc-authentication-results; bh=guOvhyEQvWnoSzpIuJcNGovVqnGsY0eB5Ar5vjatuWU=; b=qXpGM2KCVKp9Xu/pj3Zs2yPZNNOhiw2PgjGmdAuCwRV4SWWrQs9lOA9L8JJDc5ijbM j2TUwXezQ8RPC4hhbA7uHJ6fhlvkYIIdtQcuFfWePB5u248K3sC6MM9L8NtEFKK3SWbo igv5WnqqGPXoTh163OFA5bkLCHV29Aw6Y0rXCH1RSqG1jJ1vRTTRZluYFkley5QilxkO FiBueAzVVL2U1d6CzvuOydFu/tT92yQQpx7FzAzMP0MUbnyIy43zJTtTbFe/5Vv+Vm3+ htbZMdjIe2kaHkrIw5pyWfc2lnv25rRgcUBBjnUIFkFOChx/Ky4AbK+zedS+oeW8uETq 5k3g== 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 f34-v6si15336076ple.330.2018.03.08.11.58.08; Thu, 08 Mar 2018 11:58:22 -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 S932147AbeCHT43 (ORCPT + 99 others); Thu, 8 Mar 2018 14:56:29 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:43176 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752318AbeCHTwg (ORCPT ); Thu, 8 Mar 2018 14:52:36 -0500 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 CEF1080D; Thu, 8 Mar 2018 11:52:35 -0800 (PST) Received: from [192.168.100.244] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 90ADD3F24A; Thu, 8 Mar 2018 11:52:34 -0800 (PST) Subject: Re: [PATCH v7 05/13] ACPI/PPTT: Add Processor Properties Topology Table parsing To: Ard Biesheuvel Cc: linux-acpi@vger.kernel.org, Mark Rutland , austinwc@codeaurora.org, tnowicki@caviumnetworks.com, Catalin Marinas , palmer@sifive.com, Will Deacon , linux-riscv@lists.infradead.org, morten.rasmussen@arm.com, vkilari@codeaurora.org, Lorenzo Pieralisi , Al Stone , Len Brown , John Garry , wangxiongfeng2@huawei.com, dietmar.eggemann@arm.com, linux-arm-kernel , Greg Kroah-Hartman , "Rafael J. Wysocki" , Linux Kernel Mailing List , Hanjun Guo , Sudeep Holla References: <20180228220619.6992-1-jeremy.linton@arm.com> <20180228220619.6992-6-jeremy.linton@arm.com> From: Jeremy Linton Message-ID: Date: Thu, 8 Mar 2018 13:52:33 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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 Hi, On 03/08/2018 10:39 AM, Ard Biesheuvel wrote: > On 28 February 2018 at 22:06, Jeremy Linton wrote: >> ACPI 6.2 adds a new table, which describes how processing units >> are related to each other in tree like fashion. Caches are >> also sprinkled throughout the tree and describe the properties >> of the caches in relation to other caches and processing units. >> >> Add the code to parse the cache hierarchy and report the total >> number of levels of cache for a given core using >> acpi_find_last_cache_level() as well as fill out the individual >> cores cache information with cache_setup_acpi() once the >> cpu_cacheinfo structure has been populated by the arch specific >> code. >> >> An additional patch later in the set adds the ability to report >> peers in the topology using find_acpi_cpu_topology() >> to report a unique ID for each processing unit at a given level >> in the tree. These unique id's can then be used to match related >> processing units which exist as threads, COD (clusters >> on die), within a given package, etc. >> >> Signed-off-by: Jeremy Linton >> --- >> drivers/acpi/pptt.c | 488 ++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 488 insertions(+) >> create mode 100644 drivers/acpi/pptt.c >> >> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c >> new file mode 100644 >> index 000000000000..883e4318c6cd >> --- /dev/null >> +++ b/drivers/acpi/pptt.c > ... >> +/* total number of attributes checked by the properties code */ >> +#define PPTT_CHECKED_ATTRIBUTES 4 >> + >> +/* >> + * The ACPI spec implies that the fields in the cache structures are used to >> + * extend and correct the information probed from the hardware. Lets only >> + * set fields that we determine are VALID. >> + */ >> +static void update_cache_properties(struct cacheinfo *this_leaf, >> + struct acpi_pptt_cache *found_cache, >> + struct acpi_pptt_processor *cpu_node) >> +{ >> + int valid_flags = 0; >> + >> + if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) { >> + this_leaf->size = found_cache->size; >> + valid_flags++; >> + } >> + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { >> + this_leaf->coherency_line_size = found_cache->line_size; >> + valid_flags++; >> + } >> + if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) { >> + this_leaf->number_of_sets = found_cache->number_of_sets; >> + valid_flags++; >> + } >> + if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) { >> + this_leaf->ways_of_associativity = found_cache->associativity; >> + valid_flags++; >> + } >> + if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) { >> + switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) { >> + case ACPI_PPTT_CACHE_POLICY_WT: >> + this_leaf->attributes = CACHE_WRITE_THROUGH; >> + break; >> + case ACPI_PPTT_CACHE_POLICY_WB: >> + this_leaf->attributes = CACHE_WRITE_BACK; >> + break; >> + } >> + } >> + if (found_cache->flags & ACPI_PPTT_ALLOCATION_TYPE_VALID) { >> + switch (found_cache->attributes & ACPI_PPTT_MASK_ALLOCATION_TYPE) { >> + case ACPI_PPTT_CACHE_READ_ALLOCATE: >> + this_leaf->attributes |= CACHE_READ_ALLOCATE; >> + break; >> + case ACPI_PPTT_CACHE_WRITE_ALLOCATE: >> + this_leaf->attributes |= CACHE_WRITE_ALLOCATE; >> + break; >> + case ACPI_PPTT_CACHE_RW_ALLOCATE: >> + case ACPI_PPTT_CACHE_RW_ALLOCATE_ALT: >> + this_leaf->attributes |= >> + CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE; >> + break; >> + } >> + } >> + /* >> + * If the above flags are valid, and the cache type is NOCACHE >> + * update the cache type as well. >> + */ >> + if ((this_leaf->type == CACHE_TYPE_NOCACHE) && >> + (valid_flags == PPTT_CHECKED_ATTRIBUTES)) >> + this_leaf->type = CACHE_TYPE_UNIFIED; > > Why do we need the associativity and #sets attributes to be valid in > order to set the cache type? This happened a couple revisions ago because its better to force people to completely populate the attributes in the tables (particularly for nodes we are generating, which is what the _NOCACHE check above is detecting) and leave half of them undefined and therefor exported to user-space in a way which makes the properties unreliable across machines. > > I see how size and line size are rather fundamental properties, but > for a system cache, the geometry doesn't really matter. Originally all of them were required (to avoid having the discussion about which ones were "important"), but Sudeep was of the opinion that these were the "important" ones, I can see his point, and no one else spoke up... So, those are the ones that are required. > >> +} >> + >> +/* >> + * Update the kernel cache information for each level of cache >> + * associated with the given acpi cpu. >> + */ >> +static void cache_setup_acpi_cpu(struct acpi_table_header *table, >> + unsigned int cpu) >> +{ >> + struct acpi_pptt_cache *found_cache; >> + struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu); >> + u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); >> + struct cacheinfo *this_leaf; >> + unsigned int index = 0; >> + struct acpi_pptt_processor *cpu_node = NULL; >> + >> + while (index < get_cpu_cacheinfo(cpu)->num_leaves) { >> + this_leaf = this_cpu_ci->info_list + index; >> + found_cache = acpi_find_cache_node(table, acpi_cpu_id, >> + this_leaf->type, >> + this_leaf->level, >> + &cpu_node); >> + pr_debug("found = %p %p\n", found_cache, cpu_node); >> + if (found_cache) >> + update_cache_properties(this_leaf, >> + found_cache, >> + cpu_node); >> + >> + index++; >> + } >> +} >> + >> +/** >> + * acpi_find_last_cache_level() - Determines the number of cache levels for a PE >> + * @cpu: Kernel logical cpu number >> + * >> + * Given a logical cpu number, returns the number of levels of cache represented >> + * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0 >> + * indicating we didn't find any cache levels. >> + * >> + * Return: Cache levels visible to this core. >> + */ >> +int acpi_find_last_cache_level(unsigned int cpu) >> +{ >> + u32 acpi_cpu_id; >> + struct acpi_table_header *table; >> + int number_of_levels = 0; >> + acpi_status status; >> + >> + pr_debug("Cache Setup find last level cpu=%d\n", cpu); >> + >> + acpi_cpu_id = get_acpi_id_for_cpu(cpu); >> + status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); >> + if (ACPI_FAILURE(status)) { >> + pr_err_once("No PPTT table found, cache topology may be inaccurate\n"); >> + } else { >> + number_of_levels = acpi_find_cache_levels(table, acpi_cpu_id); >> + acpi_put_table(table); >> + } >> + pr_debug("Cache Setup find last level level=%d\n", number_of_levels); >> + >> + return number_of_levels; >> +} >> + >> +/** >> + * cache_setup_acpi() - Override CPU cache topology with data from the PPTT >> + * @cpu: Kernel logical cpu number >> + * >> + * Updates the global cache info provided by cpu_get_cacheinfo() >> + * when there are valid properties in the acpi_pptt_cache nodes. A >> + * successful parse may not result in any updates if none of the >> + * cache levels have any valid flags set. Futher, a unique value is >> + * associated with each known CPU cache entry. This unique value >> + * can be used to determine whether caches are shared between cpus. >> + * >> + * Return: -ENOENT on failure to find table, or 0 on success >> + */ >> +int cache_setup_acpi(unsigned int cpu) >> +{ >> + struct acpi_table_header *table; >> + acpi_status status; >> + >> + pr_debug("Cache Setup ACPI cpu %d\n", cpu); >> + >> + status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); >> + if (ACPI_FAILURE(status)) { >> + pr_err_once("No PPTT table found, cache topology may be inaccurate\n"); >> + return -ENOENT; >> + } >> + >> + cache_setup_acpi_cpu(table, cpu); >> + acpi_put_table(table); >> + >> + return status; >> +} >> -- >> 2.13.6 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel