All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] arm64: Use static keys for CPU features
Date: Thu, 8 Sep 2016 14:40:25 +0100	[thread overview]
Message-ID: <20160908134025.2nq3e5ohienesrae@localhost> (raw)
In-Reply-To: <48d10fa1-ee4c-e398-b5ae-9815bf0f18eb@akamai.com>

On Wed, Sep 07, 2016 at 12:59:52PM -0400, Jason Baron wrote:
> On 09/05/2016 01:25 PM, Catalin Marinas wrote:
> > This patch adds static keys transparently for all the cpu_hwcaps
> > features by implementing an array of default-false static keys and
> > enabling them when detected. The cpus_have_cap() check uses the static
> > keys if the feature being checked is a constant, otherwise the compiler
> > generates the bitmap test.
> > 
> > Because of the early call to static_branch_enable() via
> > check_local_cpu_errata() -> update_cpu_capabilities(), the jump labels
> > are initialised in cpuinfo_store_boot_cpu().
> 
> Was there a reason the jump_label_init() couldn't be moved
> earlier in the common code?

No particular reason, only that I wasn't sure what the arch requirements
to be able to initialise the jump labels early are (for example,
jump_label_init() calls arch_jump_label_transform_static(); there don't
seem to be any issues at a first look but I don't have the hardware to
test and confirm). Therefore I followed the powerpc idea of calling
jump_label_init() directly earlier.

We also don't know how early it needs to be to benefit other
architectures (powerpc seems to call it on a very early path via
early_setup()).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Jason Baron <jbaron@akamai.com>
Cc: Will Deacon <will.deacon@arm.com>,
	peterz@infradead.org, Suzuki.Poulose@arm.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, corbet@lwn.net
Subject: Re: [PATCH v2 2/2] arm64: Use static keys for CPU features
Date: Thu, 8 Sep 2016 14:40:25 +0100	[thread overview]
Message-ID: <20160908134025.2nq3e5ohienesrae@localhost> (raw)
In-Reply-To: <48d10fa1-ee4c-e398-b5ae-9815bf0f18eb@akamai.com>

On Wed, Sep 07, 2016 at 12:59:52PM -0400, Jason Baron wrote:
> On 09/05/2016 01:25 PM, Catalin Marinas wrote:
> > This patch adds static keys transparently for all the cpu_hwcaps
> > features by implementing an array of default-false static keys and
> > enabling them when detected. The cpus_have_cap() check uses the static
> > keys if the feature being checked is a constant, otherwise the compiler
> > generates the bitmap test.
> > 
> > Because of the early call to static_branch_enable() via
> > check_local_cpu_errata() -> update_cpu_capabilities(), the jump labels
> > are initialised in cpuinfo_store_boot_cpu().
> 
> Was there a reason the jump_label_init() couldn't be moved
> earlier in the common code?

No particular reason, only that I wasn't sure what the arch requirements
to be able to initialise the jump labels early are (for example,
jump_label_init() calls arch_jump_label_transform_static(); there don't
seem to be any issues at a first look but I don't have the hardware to
test and confirm). Therefore I followed the powerpc idea of calling
jump_label_init() directly earlier.

We also don't know how early it needs to be to benefit other
architectures (powerpc seems to call it on a very early path via
early_setup()).

-- 
Catalin

  reply	other threads:[~2016-09-08 13:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-05 17:25 [PATCH v2 0/2] arm64: Use static keys for CPU features Catalin Marinas
2016-09-05 17:25 ` Catalin Marinas
2016-09-05 17:25 ` [PATCH v2 1/2] jump_labels: Allow array initialisers Catalin Marinas
2016-09-05 17:25   ` Catalin Marinas
2016-09-06 18:11   ` Will Deacon
2016-09-06 18:11     ` Will Deacon
2016-09-06 18:50     ` Peter Zijlstra
2016-09-06 18:50       ` Peter Zijlstra
2016-09-05 17:25 ` [PATCH v2 2/2] arm64: Use static keys for CPU features Catalin Marinas
2016-09-05 17:25   ` Catalin Marinas
2016-09-07 16:59   ` Jason Baron
2016-09-07 16:59     ` Jason Baron
2016-09-08 13:40     ` Catalin Marinas [this message]
2016-09-08 13:40       ` Catalin Marinas

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=20160908134025.2nq3e5ohienesrae@localhost \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.