Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1319154 > unrolled thread
| Started by | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| First post | 2016-01-27 18:00 +0100 |
| Last post | 2016-01-27 19:50 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[RFC PATCH v2 2/3] getcpu_cache: wire up ARM system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 18:00 +0100
Re: [RFC PATCH v2 2/3] getcpu_cache: wire up ARM system call Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-01-27 19:20 +0100
Re: [RFC PATCH v2 2/3] getcpu_cache: wire up ARM system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-01-27 19:50 +0100
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-01-27 18:00 +0100 |
| Subject | [RFC PATCH v2 2/3] getcpu_cache: wire up ARM system call |
| Message-ID | <qVBBL-6sQ-1@gated-at.bofh.it> |
Wire up the getcpu cache system call on 32-bit ARM. Call the
getcpu_cache_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.
This provides an ABI improving the speed of a getcpu operation
on ARM by skipping the getcpu system call on the fast path.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Paul Turner <pjt@google.com>
CC: Andrew Hunter <ahh@google.com>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Andy Lutomirski <luto@amacapital.net>
CC: Andi Kleen <andi@firstfloor.org>
CC: Dave Watson <davejwatson@fb.com>
CC: Chris Lameter <cl@linux.com>
CC: Ingo Molnar <mingo@redhat.com>
CC: Ben Maurer <bmaurer@fb.com>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC: Josh Triplett <josh@joshtriplett.org>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: linux-api@vger.kernel.org
---
arch/arm/include/uapi/asm/unistd.h | 1 +
arch/arm/kernel/calls.S | 1 +
arch/arm/kernel/signal.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/include/uapi/asm/unistd.h b/arch/arm/include/uapi/asm/unistd.h
index ede692f..ea0ea94 100644
--- a/arch/arm/include/uapi/asm/unistd.h
+++ b/arch/arm/include/uapi/asm/unistd.h
@@ -417,6 +417,7 @@
#define __NR_userfaultfd (__NR_SYSCALL_BASE+388)
#define __NR_membarrier (__NR_SYSCALL_BASE+389)
#define __NR_mlock2 (__NR_SYSCALL_BASE+390)
+#define __NR_getcpu_cache (__NR_SYSCALL_BASE+391)
/*
* The following SWIs are ARM private.
diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S
index ac368bb..aa43e29 100644
--- a/arch/arm/kernel/calls.S
+++ b/arch/arm/kernel/calls.S
@@ -400,6 +400,7 @@
CALL(sys_userfaultfd)
CALL(sys_membarrier)
CALL(sys_mlock2)
+/* 391 */ CALL(sys_getcpu_cache)
#ifndef syscalls_counted
.equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls
#define syscalls_counted
diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index 7b8f214..ff5052c 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -594,6 +594,7 @@ do_work_pending(struct pt_regs *regs, unsigned int thread_flags, int syscall)
} else {
clear_thread_flag(TIF_NOTIFY_RESUME);
tracehook_notify_resume(regs);
+ getcpu_cache_handle_notify_resume(current);
}
}
local_irq_disable();
--
2.1.4
[toc] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2016-01-27 19:20 +0100 |
| Message-ID | <qVCRe-7CM-51@gated-at.bofh.it> |
| In reply to | #1319154 |
On Wed, Jan 27, 2016 at 11:54:42AM -0500, Mathieu Desnoyers wrote: > Wire up the getcpu cache system call on 32-bit ARM. Call the You should note that your chosen system call number of 391 is temporary here and can't be relied upon as we have to wire up the new copy_file_range() call on ARM (which I've just committed the patch for.) I'd much prefer the wiring up to be either an entirely separate patch (which must be submitted to me, and I'll merge between -rc1 and -rc2 along with any other syscall updates) or you leave the wiring up to me. This is so that I can ensure that (a) system calls numbers are not duplicated and (b) ensure that we follow the same logical order as x86 where possible. Thanks. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-01-27 19:50 +0100 |
| Message-ID | <qVDke-7RP-11@gated-at.bofh.it> |
| In reply to | #1319222 |
----- On Jan 27, 2016, at 1:19 PM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
> On Wed, Jan 27, 2016 at 11:54:42AM -0500, Mathieu Desnoyers wrote:
>> Wire up the getcpu cache system call on 32-bit ARM. Call the
>
> You should note that your chosen system call number of 391 is temporary
> here and can't be relied upon as we have to wire up the new
> copy_file_range() call on ARM (which I've just committed the patch for.)
>
> I'd much prefer the wiring up to be either an entirely separate patch
> (which must be submitted to me, and I'll merge between -rc1 and -rc2
> along with any other syscall updates) or you leave the wiring up to me.
>
> This is so that I can ensure that (a) system calls numbers are not
> duplicated and (b) ensure that we follow the same logical order as x86
> where possible.
Just to make sure I understand: you would perfer if I split this
patch into two: one that adds the getcpu_cache_handle_notify_resume()
call in the resume notifier ("getcpu_cache ARM architecture support"),
and a separate patch for wiring up the system call ?
Thanks,
Mathieu
>
> Thanks.
>
> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web