From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: implement optimized percpu variable access
Date: Mon, 26 Nov 2012 11:13:37 +0000 [thread overview]
Message-ID: <20121126111337.GA13312@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <50B2679F.3070107@gmail.com>
Hi Rob,
On Sun, Nov 25, 2012 at 06:46:55PM +0000, Rob Herring wrote:
> On 11/22/2012 05:34 AM, Will Deacon wrote:
> > As an aside, you also need to make the asm block volatile in
> > __my_cpu_offset -- I can see it being re-ordered before the set for
> > secondary CPUs otherwise.
>
> I don't think that is right. Doing that means the register is reloaded
> on every access and you end up with code like this (from handle_IRQ):
>
> c000eb4c: ee1d2f90 mrc 15, 0, r2, cr13, cr0, {4}
> c000eb50: e7926003 ldr r6, [r2, r3]
> c000eb54: ee1d2f90 mrc 15, 0, r2, cr13, cr0, {4}
> c000eb58: e7821003 str r1, [r2, r3]
> c000eb5c: eb006cb1 bl c0029e28 <irq_enter>
>
> I don't really see where there would be a re-ordering issue. There's no
> percpu var access before or near the setting that I can see.
Well my A15 doesn't boot with your original patch unless I make that thing
volatile, so something does need tweaking...
The issue is on bringing up the secondary core, so I assumed that a lot
of inlining goes on inside secondary_start_kernel and then the result is
shuffled around, placing a cpu-offset read before we've done the set.
Unfortunately, looking at the disassembly I can't see this happening at
all, so I'll keep digging. The good news is that I've just reproduced the
problem on the model, so I've got more visibility now (although both cores
are just stuck in spinlocks...).
Will
next prev parent reply other threads:[~2012-11-26 11:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-11 3:20 [PATCH] ARM: implement optimized percpu variable access Rob Herring
2012-11-12 10:23 ` Will Deacon
2012-11-12 13:03 ` Rob Herring
2012-11-12 13:28 ` Will Deacon
2012-11-12 14:03 ` Rob Herring
2012-11-27 17:29 ` Nicolas Pitre
2012-11-12 14:21 ` Rob Herring
2012-11-12 14:41 ` Will Deacon
2012-11-12 16:51 ` Will Deacon
2012-11-12 21:01 ` Rob Herring
2012-11-13 10:40 ` Will Deacon
2012-11-22 11:34 ` Will Deacon
2012-11-22 11:39 ` Russell King - ARM Linux
2012-11-23 17:06 ` Rob Herring
2012-11-23 17:12 ` Russell King - ARM Linux
2012-11-23 17:16 ` Will Deacon
2012-11-23 20:34 ` Tony Lindgren
2012-11-23 20:32 ` Tony Lindgren
2012-11-25 18:46 ` Rob Herring
2012-11-26 11:13 ` Will Deacon [this message]
2012-11-26 15:15 ` Will Deacon
2012-11-26 17:30 ` Rob Herring
2012-11-27 13:17 ` Will Deacon
2012-11-27 13:26 ` Russell King - ARM Linux
2012-11-26 21:58 ` Jamie Lokier
2012-11-26 23:50 ` Jamie Lokier
2012-11-27 1:02 ` Jamie Lokier
2012-11-27 22:02 ` Rob Herring
2012-11-28 12:34 ` Will Deacon
2012-11-27 17:35 ` Nicolas Pitre
2012-11-27 19:27 ` Nicolas Pitre
2012-11-27 17:19 ` Nicolas Pitre
2012-11-27 19:37 ` Rob Herring
2012-11-27 20:42 ` Rob Herring
2012-11-27 22:02 ` Nicolas Pitre
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=20121126111337.GA13312@mudshark.cambridge.arm.com \
--to=will.deacon@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 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).