From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3] arm64: percpu: Implement this_cpu operations
Date: Fri, 14 Nov 2014 13:46:45 +0000 [thread overview]
Message-ID: <20141114134644.GD27963@arm.com> (raw)
In-Reply-To: <1415965077-10495-1-git-send-email-steve.capper@linaro.org>
Hi Steve,
On Fri, Nov 14, 2014 at 11:37:57AM +0000, Steve Capper wrote:
> The generic this_cpu operations disable interrupts to ensure that the
> requested operation is protected from pre-emption. For arm64, this is
> overkill and can hurt throughput and latency.
>
> This patch provides arm64 specific implementations for the this_cpu
> operations. Rather than disable interrupts, we use the exclusive
> monitor or atomic operations as appropriate.
>
> The following operations are implemented: add, add_return, and, or,
> read, write, xchg. We also wire up a cmpxchg implementation from
> cmpxchg.h.
>
> Testing was performed using the percpu_test module and hackbench on a
> Juno board running 3.18-rc4.
What does this patch apply against? I'm struggling to apply it to our
for-next branch (perhaps it conflicts with your other cmpxchg patch?)
Anyway, one comment below.
> +static inline unsigned long __percpu_read(void *ptr, int size)
> +{
> + unsigned long ret;
> +
> + switch (size) {
> + case 1:
> + asm ("//__per_cpu_read_1\n"
> + "ldrb %w[ret], %[ptr]\n" :
> + [ret] "=&r"(ret) : [ptr] "Q"(*(u8 *)ptr));
> + break;
> + case 2:
> + asm ("//__per_cpu_read_2\n"
> + "ldrh %w[ret], %[ptr]\n" :
> + [ret] "=&r"(ret) : [ptr] "Q"(*(u16 *)ptr));
> + break;
> + case 4:
> + asm ("//__per_cpu_read_4\n"
> + "ldr %w[ret], %[ptr]\n" :
> + [ret] "=&r"(ret) : [ptr] "Q"(*(u32 *)ptr));
> + break;
> + case 8:
> + asm ("//__per_cpu_read_8\n"
> + "ldr %[ret], %[ptr]\n" :
> + [ret] "=&r"(ret) : [ptr] "Q"(*(u64 *)ptr));
> + break;
> + default:
> + BUILD_BUG();
> + }
> +
> + return ret;
> +}
> +
> +static inline void __percpu_write(void *ptr, unsigned long val, int size)
> +{
> + switch (size) {
> + case 1:
> + asm ("//__per_cpu_write_1\n"
> + "strb %w[val], %[ptr]\n" :
> + [ptr] "=Q"(*(u8 *)ptr) : [val] "r"(val));
> + break;
> + case 2:
> + asm ("//__per_cpu_write_2\n"
> + "strh %w[val], %[ptr]\n" :
> + [ptr] "=Q"(*(u16 *)ptr) : [val] "r"(val));
> + break;
> + case 4:
> + asm ("//__per_cpu_write_4\n"
> + "str %w[val], %[ptr]\n" :
> + [ptr] "=Q"(*(u32 *)ptr) : [val] "r"(val));
> + break;
> + case 8:
> + asm ("//__per_cpu_write_8\n"
> + "str %[val], %[ptr]\n" :
> + [ptr] "=Q"(*(u64 *)ptr) : [val] "r"(val));
> + break;
> + default:
> + BUILD_BUG();
> + }
> +}
Can you implement the read/write accessors with ACCESS_ONCE instead?
I think we're just after a single-copy atomic access without barrier
semantics, so that should work if you get your types right.
Will
next prev parent reply other threads:[~2014-11-14 13:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 11:12 [PATCH] arm64: percpu: Implement this_cpu operations Steve Capper
2014-11-06 11:26 ` Ard Biesheuvel
2014-11-06 11:52 ` Steve Capper
2014-11-06 12:23 ` [PATCH V2] " Steve Capper
2014-11-06 12:27 ` [PATCH] " Will Deacon
2014-11-07 13:52 ` Steve Capper
2014-11-14 11:37 ` [PATCH V3] " Steve Capper
2014-11-14 13:46 ` Will Deacon [this message]
2014-11-14 15:03 ` [PATCH V4] " Steve Capper
2014-11-17 10:40 ` Will Deacon
2014-11-19 15:49 ` Steve Capper
2014-11-19 16:53 ` [PATCH V5] " Steve Capper
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=20141114134644.GD27963@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).