Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp465143imu; Mon, 5 Nov 2018 03:58:31 -0800 (PST) X-Google-Smtp-Source: AJdET5fkxYX0MDM7Z1cz9Of68lElJK1zuH9xZr+7acJ48y1vWVDKRvFmsvNyVE3niabet232IHss X-Received: by 2002:a63:4c6:: with SMTP id 189mr20108207pge.391.1541419111812; Mon, 05 Nov 2018 03:58:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541419111; cv=none; d=google.com; s=arc-20160816; b=caM6HAFJVTdSagJoSWkuP82s8w/grgERdhFUpUcXm0mxj7dYWSdVfo0wIdsDfOSvQH 58IUq27KwJ2ymllPEjFzClH5ZVlQOo2VJt0WL5X62httN1EFCM0ZyQbsc5miOxf1woCs 9JTwJaEt6Oficq0omckaCgmIPE+X9y7OkQetyaf9NH7PwQhqgIOfSnGoGR6MC5YQQ8Or pDVB5rKj7TCF6lBZbfmvtIqYHVlHsdmbt689UYtMxOj3OsMpTP9fxO5KBki+lsSOszUM f6OO/80J+9LW8uC1Wts3T2CLyUX9hbJI/vEpONo4tkmWVfTkmSsiLjfrKoWmrzCuVtoL q//Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=5aeEgLcx+TLRiM3QoKzymTetTn4tlx/Z0LzyTiczN9E=; b=ZQCZl+U9fBzKtLGpSGu1ky4FCKYLngqWRJ9BF5xFhWzhXH5fovl0e/VVP0GcGjZTEe dWw/MWHsTMXtGDtPfDvvuhSWiUNJYk2pKIqkZhaiKGhsZ+P4EJ1VWqKrh1kpxxokdVO9 9CLFMjFHc7HiyqpibdRpH2xI1wG9QAD/0K404ros+IHoXQHK0qlLLcgWqgGmC0i6Hjeg U+OsCE2DvGEeVcbzZ6b3EzM55fdIeZ9pDWIwbUfMTmxPfKZvIVvU9mLqbh5IsR8QF9Gt KIR6jcSk0BXfAEfNuf43uKJ/cUMBB+RJfJDSbELc9DgCtvieJk0T8w/gs/mbAEHlF0Uh CFJw== 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 31-v6si14845216plz.181.2018.11.05.03.58.16; Mon, 05 Nov 2018 03:58:31 -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 S1729017AbeKEVPF (ORCPT + 99 others); Mon, 5 Nov 2018 16:15:05 -0500 Received: from foss.arm.com ([217.140.101.70]:41764 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728850AbeKEVPE (ORCPT ); Mon, 5 Nov 2018 16:15:04 -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 A38A480D; Mon, 5 Nov 2018 03:55:42 -0800 (PST) Received: from en101.cambridge.arm.com (en101.cambridge.arm.com [10.1.196.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4E7413F5BD; Mon, 5 Nov 2018 03:55:41 -0800 (PST) From: Suzuki K Poulose To: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, vladimir.murzin@arm.com, will.deacon@arm.com, catalin.marinas@arm.com, mark.rutland@arm.com, Suzuki K Poulose Subject: [PATCH 0/7] arm64: capabilities: Optimize checking and enabling Date: Mon, 5 Nov 2018 11:55:10 +0000 Message-Id: <1541418917-14219-1-git-send-email-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We maintain two separate tables (i.e, arm64_features and arm64_errata) of struct arm64_cpu_capabilities which decide the capabilities of the system. We iterate over the two tables for detecting/verifying/enabling the capabilities. e.g, this_cpu_has_cap() needs to iterate over the two tables one by one to find the "capability" structure corresponding to the cap number and then check it on the CPU. Also, we enable all the non-boot scoped capabilities after all the SMP cpus are brought up by the kernel, using stop_machine() for each available capability. We could batch all the "enabling" activity to a single stop_machine() callback. But that implies you need a way to map a given capability number to the corresponding capability entry to finish the operation quickly. So we need a quicker way to access the entry for a given capability. We have two choices : 1) Unify both the tables to a static/dynamic sorted entry based on the capability number. This has the following drawbacks : a) The entries must be unique. i.e, no duplicate entries for a capability. b) Looses the separation of "features" vs. "errata" classification c) Statically sorting the list is error prone. Runtime sorting the array means more time for booting. 2) Keep an array of pointers to the capability sorted at boot time based on the capability. a) As for (1), the entries must be unique for a capability. This series implements (2) and uses the new list for optimizing the operations on the entries. As a prepatory step, we remove the duplicate entries for the same capabilities (Patch 1-3). Suzuki K Poulose (7): arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE arm64: capabilities: Merge duplicate Cavium erratum entries arm64: capabilities: Merge duplicate entries for Qualcomm erratum 1003 arm64: capabilities: Speed up capability lookup arm64: capabilities: Optimize this_cpu_has_cap arm64: capabilities: Use linear array for detection and verification arm64: capabilities: Batch cpu_enable callbacks arch/arm64/include/asm/cpufeature.h | 3 + arch/arm64/include/asm/cputype.h | 2 + arch/arm64/kernel/cpu_errata.c | 94 ++++++++++---------- arch/arm64/kernel/cpufeature.c | 165 ++++++++++++++++++++---------------- 4 files changed, 145 insertions(+), 119 deletions(-) -- 2.7.4