Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1288610 > unrolled thread

[RFC PATCH 2/2] thread_local_abi: wire up ARM system call

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.

Contents

  [RFC PATCH 2/2] thread_local_abi: wire up ARM system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2015-12-10 16:50 +0100
    Re: [RFC PATCH 2/2] thread_local_abi: wire up ARM system call Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-12-10 17:30 +0100
      Re: [RFC PATCH 2/2] thread_local_abi: wire up ARM system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2015-12-10 18:10 +0100

#1288610 — [RFC PATCH 2/2] thread_local_abi: wire up ARM system call

Wire up the thread local ABI on ARM32. Call the
getcpu_cache_handle_notify_resume() function on return to userspace if
TIF_NOTIFY_RESUME thread flag is set.

This provides a way to implement a sched_getcpu() on ARM without
requiring to perform a system call on the fast path.

[ Untested. ]

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/asm/unistd.h      | 2 +-
 arch/arm/include/uapi/asm/unistd.h | 1 +
 arch/arm/kernel/calls.S            | 1 +
 arch/arm/kernel/signal.c           | 2 ++
 4 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
index 7b84657..ef55382 100644
--- a/arch/arm/include/asm/unistd.h
+++ b/arch/arm/include/asm/unistd.h
@@ -19,7 +19,7 @@
  * This may need to be greater than __NR_last_syscall+1 in order to
  * account for the padding in the syscall table
  */
-#define __NR_syscalls  (392)
+#define __NR_syscalls  (393)
 
 #define __ARCH_WANT_STAT64
 #define __ARCH_WANT_SYS_GETHOSTNAME
diff --git a/arch/arm/include/uapi/asm/unistd.h b/arch/arm/include/uapi/asm/unistd.h
index 7a2a32a..859433a 100644
--- a/arch/arm/include/uapi/asm/unistd.h
+++ b/arch/arm/include/uapi/asm/unistd.h
@@ -416,6 +416,7 @@
 #define __NR_execveat			(__NR_SYSCALL_BASE+387)
 #define __NR_userfaultfd		(__NR_SYSCALL_BASE+388)
 #define __NR_membarrier			(__NR_SYSCALL_BASE+389)
+#define __NR_thread_local_abi		(__NR_SYSCALL_BASE+390)
 
 /*
  * The following SWIs are ARM private.
diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S
index fde6c88..82b59cc 100644
--- a/arch/arm/kernel/calls.S
+++ b/arch/arm/kernel/calls.S
@@ -399,6 +399,7 @@
 		CALL(sys_execveat)
 		CALL(sys_userfaultfd)
 		CALL(sys_membarrier)
+/* 390 */	CALL(sys_thread_local_abi)
 #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..feaa514 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -594,6 +594,8 @@ do_work_pending(struct pt_regs *regs, unsigned int thread_flags, int syscall)
 			} else {
 				clear_thread_flag(TIF_NOTIFY_RESUME);
 				tracehook_notify_resume(regs);
+				if (getcpu_cache_active(current))
+					getcpu_cache_handle_notify_resume(current);
 			}
 		}
 		local_irq_disable();
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1288646

On Thu, Dec 10, 2015 at 10:39:50AM -0500, Mathieu Desnoyers wrote:
> Wire up the thread local ABI on ARM32. Call the
> getcpu_cache_handle_notify_resume() function on return to userspace if
> TIF_NOTIFY_RESUME thread flag is set.
> 
> This provides a way to implement a sched_getcpu() on ARM without
> requiring to perform a system call on the fast path.
> 
> [ Untested. ]

Why are you sending this _to_ Thomas?  Shouldn't you be sending it to me
as the arch maintainer?

> diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
> index 7b84657..ef55382 100644
> --- a/arch/arm/include/asm/unistd.h
> +++ b/arch/arm/include/asm/unistd.h
> @@ -19,7 +19,7 @@
>   * This may need to be greater than __NR_last_syscall+1 in order to
>   * account for the padding in the syscall table
>   */
> -#define __NR_syscalls  (392)
> +#define __NR_syscalls  (393)

That will cause a build error.  Please leave this alone until we get to
syscall 392, where upon it will need to be incremented by four.

Also, I tend to wait until after -rc1 before adding any syscalls, when
all the new syscalls are obvious and known - this avoids ending up with
two different trees having allocated the same syscall number (which is
why arch maintainers should be the only people who are responsible for
merging updates to their arch's syscall numbering.)

Sure, if multiple different people end up merging patches via different
routes, the conflicts can be resolved when those different routes come
together, but what happens if someone adds the syscall number that they
thought they had to (eg) glibc, and then have to change it later because
come -rc1 it ends up being different...

I'd much rather that all patches to unistd.h are only mergable via the
respective arch maintainers to keep the numbering sane.

(I personally want to follow x86's syscall numbering order as much as
possible.)

-- 
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1288676

----- On Dec 10, 2015, at 11:27 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:

> On Thu, Dec 10, 2015 at 10:39:50AM -0500, Mathieu Desnoyers wrote:
>> Wire up the thread local ABI on ARM32. Call the
>> getcpu_cache_handle_notify_resume() function on return to userspace if
>> TIF_NOTIFY_RESUME thread flag is set.
>> 
>> This provides a way to implement a sched_getcpu() on ARM without
>> requiring to perform a system call on the fast path.
>> 
>> [ Untested. ]
> 
> Why are you sending this _to_ Thomas?  Shouldn't you be sending it to me
> as the arch maintainer?

Thomas showed interest in trying it out on ARM, which is why I'm
sending this RFC patch "To" him. Of course, I plan to send it
to you if it goes beyond RFC stage.

> 
>> diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
>> index 7b84657..ef55382 100644
>> --- a/arch/arm/include/asm/unistd.h
>> +++ b/arch/arm/include/asm/unistd.h
>> @@ -19,7 +19,7 @@
>>   * This may need to be greater than __NR_last_syscall+1 in order to
>>   * account for the padding in the syscall table
>>   */
>> -#define __NR_syscalls  (392)
>> +#define __NR_syscalls  (393)
> 
> That will cause a build error.  Please leave this alone until we get to
> syscall 392, where upon it will need to be incremented by four.

Oops, right. Will do.

> 
> Also, I tend to wait until after -rc1 before adding any syscalls, when
> all the new syscalls are obvious and known - this avoids ending up with
> two different trees having allocated the same syscall number (which is
> why arch maintainers should be the only people who are responsible for
> merging updates to their arch's syscall numbering.)

Sounds good. Anyway please wait until I send a non-RFC patch before
doing so.

Thanks!

Mathieu

> 
> Sure, if multiple different people end up merging patches via different
> routes, the conflicts can be resolved when those different routes come
> together, but what happens if someone adds the syscall number that they
> thought they had to (eg) glibc, and then have to change it later because
> come -rc1 it ends up being different...
> 
> I'd much rather that all patches to unistd.h are only mergable via the
> respective arch maintainers to keep the numbering sane.
> 
> (I personally want to follow x86's syscall numbering order as much as
> possible.)
> 
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web