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

Groups > linux.kernel > #1370775 > unrolled thread

[RFC PATCH v6 0/5] Thread-local ABI system call (CPU number cache)

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH v6 0/5] Thread-local ABI system call (CPU number cache) Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 19:10 +0200
    [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 19:10 +0200
      Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-04-04 19:20 +0200
        Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 21:50 +0200
          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 22:50 +0200
            Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-05 18:10 +0200
              Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-04-05 18:50 +0200
                Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-07 11:10 +0200
                  Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-04-07 12:40 +0200
                    Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-07 12:40 +0200
                      Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-04-07 13:30 +0200
                        Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-07 14:10 +0200
                          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-04-07 14:30 +0200
                            Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-07 14:40 +0200
                            Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-07 18:00 +0200
                          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-07 14:40 +0200
                        Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-04-07 18:40 +0200
                          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Andy Lutomirski <luto@amacapital.net> - 2016-04-07 18:50 +0200
                          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-04-07 19:00 +0200
                          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-07 19:00 +0200
                          Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-04-07 19:00 +0200
                            Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-07 20:50 +0200
                              Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Andi Kleen <andi@firstfloor.org> - 2016-04-07 22:30 +0200
                                Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU  number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-07 23:00 +0200
      Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number  of running thread Florian Weimer <fweimer@redhat.com> - 2016-04-07 12:50 +0200
    [RFC PATCH v6 5/5] Thread-local ABI: wire up x86 32/64 system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 19:10 +0200
    [RFC PATCH v6 3/5] Thread-local ABI: wire up ARM system call Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 19:10 +0200
    [RFC PATCH v6 4/5] Thread-local ABI cpu_id: x86 32/64 resume notifier Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-04-04 19:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1373572 — Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Because if not, then this discussion is done for. Stop with the
> f*cking idiotic "let's look at some kernel size and user-space size
> and try to match them up". The kernel doesn't care. The kernel MUST
> NOT care. The kernel will touch one single word, and that's all the
> kernel does, and user space had better be able make up their own
> semantics around that.

.. and btw - if people aren't sure that that is a "good enough"
interface, then I'm sure as hell not going to merge that patch anyway.
Andy mentions rseq. Yeah, I'm not going to merge anything where part
of the discussion is "and we might want to do something else for X".

Either the suggested patches are useful and generic enough that people
can do this, or they aren't.

If people can agree that "yes, this whole cpu id cache is a great
interface that we can build up interesting user-space constructs
around", then great. Such a new kernel interface may be worth merging.

But if people cannot be convinced that it is sufficient, then I don't
want to merge some half-arsed interface that generates these kinds of
discussions.

So the fact that currently makes me go "no way will I merge any of
this" is the very fact that these discussions continue and are still
going on.

                Linus

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

#1373653 — Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

----- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

> On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Because if not, then this discussion is done for. Stop with the
>> f*cking idiotic "let's look at some kernel size and user-space size
>> and try to match them up". The kernel doesn't care. The kernel MUST
>> NOT care. The kernel will touch one single word, and that's all the
>> kernel does, and user space had better be able make up their own
>> semantics around that.
> 
> .. and btw - if people aren't sure that that is a "good enough"
> interface, then I'm sure as hell not going to merge that patch anyway.
> Andy mentions rseq. Yeah, I'm not going to merge anything where part
> of the discussion is "and we might want to do something else for X".
> 
> Either the suggested patches are useful and generic enough that people
> can do this, or they aren't.
> 
> If people can agree that "yes, this whole cpu id cache is a great
> interface that we can build up interesting user-space constructs
> around", then great. Such a new kernel interface may be worth merging.

One basic use of cpu id cache is to speed up the sched_getcpu(3)
implementation in glibc. This is why I'm proposing it as a stand-alone
feature that does not require the restartable sequences. It can
also be used directly from applications to remove the function call
overhead of sched_getcpu, which further accelerates this operation.

> 
> But if people cannot be convinced that it is sufficient, then I don't
> want to merge some half-arsed interface that generates these kinds of
> discussions.
> 
> So the fact that currently makes me go "no way will I merge any of
> this" is the very fact that these discussions continue and are still
> going on.

The intent of this RFC patchset is to get people to agree on the proper
way to introduce both the "cpu id" and the "rseq (restartable critical
section)" features. I have so far proposed two ways of doing it: one
system call per feature, or one system call to register all the features.

My previous patch rounds were adding a system call specific for the
cpu_id field, registering a pointer to a 32-bit per-thread integer.
(getcpu_cache system call) Based on prior email exchanges I had with
you on other topics, I was inclined to go for the specific getcpu_cache
system call route, and adding future features as separate system calls.

hpa pointed out that this will mean keeping track of one pointer
per task-struct for cpu_id, and eventually another pointer per
task-struct for rseq fields, thus degrading cache locality. In
order to address his concerns, I proposed this "thread local ABI"
system call, which registers a fixed-size 64 bytes structure that
starts with a feature mask.

The other route we could take is to just implement one "rseq" system
call, which would contain all fields needed for the rseq feature,
which happen to include the cpu_id. The main downside of this
approach is that whenever we want to port the cpu_id feature to
another architecture, it _needs_ to come with the implemented
"rseq" feature too, which is rather more complex. I don't mind
going that way either if that's preferred.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

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

#1373722 — Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

> One basic use of cpu id cache is to speed up the sched_getcpu(3)
> implementation in glibc. This is why I'm proposing it as a stand-alone

I don't think rseq is needed for faster getcpu.

User space has to be able handle stale return values anyways, as it
has no way to lock itself to a cpu while it is using the return value.
So it can be only a hint.

The original version of getcpu just had a jiffies based cache. The CPU
value was valid up to a jiffie (the next time jiffie changes), and then it
gets looked up again.

Processes are unlikely to switch CPUs more often than a jiffie, so it's
good enough as a hint.
 
This doesn't need any new kernel interfaces at all because jiffies is already
exported to the vdso.

It just needs a new entry point into the vdso that handles the jiffie
check.

-Andi

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

#1373761 — Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

----- On Apr 7, 2016, at 4:22 PM, Andi Kleen andi@firstfloor.org wrote:

>> One basic use of cpu id cache is to speed up the sched_getcpu(3)
>> implementation in glibc. This is why I'm proposing it as a stand-alone
> 
> I don't think rseq is needed for faster getcpu.

I agree that rseq is not needed for faster getcpu. This is why I was proposing
to make "cpu_id" feature configurable separately from the rseq feature.
E.g. a kernel configuration that don't want to take the hit of rseq handling
in signal delivery and preemption could just enable the cpu_id feature, and
thus only need to add work in the migration code path, and when returning to
userspace. Also, if a thread only registers the cpu_id feature, the kernel
can skip the rseq code quickly in signal delivery and preemption too.

> 
> User space has to be able handle stale return values anyways, as it
> has no way to lock itself to a cpu while it is using the return value.
> So it can be only a hint.
> 
> The original version of getcpu just had a jiffies based cache. The CPU
> value was valid up to a jiffie (the next time jiffie changes), and then it
> gets looked up again.
> 
> Processes are unlikely to switch CPUs more often than a jiffie, so it's
> good enough as a hint.

One example use-case where this would hurt: we use the CPU id heavily when
tracing to a ring buffer in user-space. Having one event written into the
wrong buffer once in a while is not a big deal, but tracing a whole burst
of events within a jiffy (e.g. 4ms at 250Hz) to the wrong cpu buffer
whenever the thread migrates is really an unwanted side-effect latency-wise.

> 
> This doesn't need any new kernel interfaces at all because jiffies is already
> exported to the vdso.

My understanding is that although your assumptions about availability of
those features in vdso are true for x86 32/64, but do not currently apply
to ARM32.

ARM32 is my main target architecture for the CPU id cache work. x86 32/64
simply also happen to benefit from that work too (see my benchmark numbers
in changelog of patch 1/5).

> It just needs a new entry point into the vdso that handles the jiffie
> check.

This would likely require to extend the ARM vdso page to expose the jiffies
counter to user-space, and update user-space libraries to use this counter
in sched_getcpu. But it would still be slower than the cpu_id cache I propose,
due to the required function call to sched_getcpu, unless you want to open-code
the jiffies check within all applications as an ABI. It would also be bad for
fast bursts of cpu id use (e.g. per-cpu ring buffers).

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

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

#1373268 — Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread

On 04/04/2016 07:01 PM, Mathieu Desnoyers wrote:
> NAME
>        thread_local_abi  -  Shared  memory  interface  between user-space
>        threads and the kernel

We already have set_robust_list, which is conceptually similar.

Florian

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

#1370779 — [RFC PATCH v6 5/5] Thread-local ABI: wire up x86 32/64 system call

Wire up the thread-local ABI system call on x86 32/64.

This provides an ABI improving the speed of a getcpu operation
on x86 by removing the need to perform a function call, "lsl"
instruction, or system call on the fast path.

The thread-local ABI can be extended to add features in the future.

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: "H. Peter Anvin" <hpa@zytor.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: Boqun Feng <boqun.feng@gmail.com>
CC: linux-api@vger.kernel.org
---
 arch/x86/entry/syscalls/syscall_32.tbl | 1 +
 arch/x86/entry/syscalls/syscall_64.tbl | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index cb713df..e31d5a5 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -384,3 +384,4 @@
 375	i386	membarrier		sys_membarrier
 376	i386	mlock2			sys_mlock2
 377	i386	copy_file_range		sys_copy_file_range
+378	i386	thread_local_abi	sys_thread_local_abi
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index dc1040a..6aaddb4b 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -333,6 +333,7 @@
 324	common	membarrier		sys_membarrier
 325	common	mlock2			sys_mlock2
 326	common	copy_file_range		sys_copy_file_range
+326	common	thread_local_abi	sys_thread_local_abi
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
-- 
2.1.4

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

#1370783 — [RFC PATCH v6 3/5] Thread-local ABI: wire up ARM system call

Wire up the thread-local ABI system call on 32-bit ARM.

This provides an ABI improving the speed of a getcpu operation
on ARM by skipping the getcpu system call on the fast path.

The thread-local ABI can be extended to add features in the future.

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: Boqun Feng <boqun.feng@gmail.com>
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            | 3 ++-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
index 7b84657..194b699 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  (396)
 
 #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 5dd2528..aaa9221 100644
--- a/arch/arm/include/uapi/asm/unistd.h
+++ b/arch/arm/include/uapi/asm/unistd.h
@@ -418,6 +418,7 @@
 #define __NR_membarrier			(__NR_SYSCALL_BASE+389)
 #define __NR_mlock2			(__NR_SYSCALL_BASE+390)
 #define __NR_copy_file_range		(__NR_SYSCALL_BASE+391)
+#define __NR_thread_local_abi		(__NR_SYSCALL_BASE+392)
 
 /*
  * The following SWIs are ARM private.
diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S
index dfc7cd6..d6a0fe9 100644
--- a/arch/arm/kernel/calls.S
+++ b/arch/arm/kernel/calls.S
@@ -399,8 +399,9 @@
 		CALL(sys_execveat)
 		CALL(sys_userfaultfd)
 		CALL(sys_membarrier)
-		CALL(sys_mlock2)
+/* 390 */	CALL(sys_mlock2)
 		CALL(sys_copy_file_range)
+		CALL(sys_thread_local_abi)
 #ifndef syscalls_counted
 .equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls
 #define syscalls_counted
-- 
2.1.4

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

#1370785 — [RFC PATCH v6 4/5] Thread-local ABI cpu_id: x86 32/64 resume notifier

Call the tlabi_cpu_id_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.

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: "H. Peter Anvin" <hpa@zytor.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: Boqun Feng <boqun.feng@gmail.com>
CC: linux-api@vger.kernel.org
---
 arch/x86/entry/common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 0366374..8dbdde5 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -249,6 +249,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 cached_flags)
 		if (cached_flags & _TIF_NOTIFY_RESUME) {
 			clear_thread_flag(TIF_NOTIFY_RESUME);
 			tracehook_notify_resume(regs);
+			tlabi_cpu_id_handle_notify_resume(current);
 		}
 
 		if (cached_flags & _TIF_USER_RETURN_NOTIFY)
-- 
2.1.4

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web