linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
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 <suzuki.poulose@arm.com>
Subject: [PATCH 0/7] arm64: capabilities: Optimize checking and enabling
Date: Mon,  5 Nov 2018 11:55:10 +0000	[thread overview]
Message-ID: <1541418917-14219-1-git-send-email-suzuki.poulose@arm.com> (raw)

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


             reply	other threads:[~2018-11-05 11:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 11:55 Suzuki K Poulose [this message]
2018-11-05 11:55 ` [PATCH 1/7] arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE Suzuki K Poulose
2018-11-26 14:06   ` Will Deacon
2018-11-26 15:09     ` Suzuki K Poulose
2018-11-27 19:31       ` Will Deacon
2018-11-05 11:55 ` [PATCH 2/7] arm64: capabilities: Merge duplicate Cavium erratum entries Suzuki K Poulose
2018-11-05 11:55 ` [PATCH 3/7] arm64: capabilities: Merge duplicate entries for Qualcomm erratum 1003 Suzuki K Poulose
2018-11-05 11:55 ` [PATCH 4/7] arm64: capabilities: Speed up capability lookup Suzuki K Poulose
2018-11-05 11:55 ` [PATCH 5/7] arm64: capabilities: Optimize this_cpu_has_cap Suzuki K Poulose
2018-11-05 11:55 ` [PATCH 6/7] arm64: capabilities: Use linear array for detection and verification Suzuki K Poulose
2018-11-05 11:55 ` [PATCH 7/7] arm64: capabilities: Batch cpu_enable callbacks Suzuki K Poulose
2018-11-05 12:14 ` [PATCH 0/7] arm64: capabilities: Optimize checking and enabling Vladimir Murzin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1541418917-14219-1-git-send-email-suzuki.poulose@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=vladimir.murzin@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).