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 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.