Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1341168 > unrolled thread
| Started by | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| First post | 2016-02-24 00:30 +0100 |
| Last post | 2016-02-27 16:10 +0100 |
| Articles | 20 on this page of 42 — 8 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.
[PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-24 00:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-02-24 12:20 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-24 18:20 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-02-26 00:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-26 18:50 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-25 11:00 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-25 18:00 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-25 18:10 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-25 18:20 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-26 12:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-02-26 17:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-26 18:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Thomas Gleixner <tglx@linutronix.de> - 2016-02-26 19:10 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-26 21:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 00:10 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-27 01:50 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 07:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-27 15:20 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-27 16:00 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-27 19:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 20:10 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-28 01:00 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 02:00 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-28 15:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-29 11:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-03-01 21:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-03-01 22:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-03-01 22:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-03-01 23:00 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-03-02 11:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-29 11:40 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Arnd Bergmann <arnd@arndb.de> - 2016-02-29 11:50 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-29 13:50 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Arnd Bergmann <arnd@arndb.de> - 2016-02-29 14:20 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-29 19:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Geert Uytterhoeven <geert@linux-m68k.org> - 2016-03-02 11:50 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-03-01 19:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-03-01 19:50 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Geert Uytterhoeven <geert@linux-m68k.org> - 2016-02-28 14:10 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 17:30 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-29 11:10 +0100
Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 16:10 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-24 00:30 +0100 |
| Subject | [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r5uz0-4cb-19@gated-at.bofh.it> |
Expose a new system call allowing threads to register one userspace
memory area where to store the CPU number on which the calling thread is
running. Scheduler migration sets the TIF_NOTIFY_RESUME flag on the
current thread. Upon return to user-space, a notify-resume handler
updates the current CPU value within each registered user-space memory
area. User-space can then read the current CPU number directly from
memory.
This getcpu cache is an improvement over current mechanisms available to
read the current CPU number, which has the following benefits:
- 44x speedup on ARM vs system call through glibc,
- 14x speedup on x86 compared to calling glibc, which calls vdso
executing a "lsl" instruction,
- 11x speedup on x86 compared to inlined "lsl" instruction,
- Unlike vdso approaches, this cached value can be read from an inline
assembly, which makes it a useful building block for restartable
sequences.
- The getcpu cache approach is portable (e.g. ARM), which is not the
case for the lsl-based x86 vdso.
On x86, yet another possible approach would be to use the gs segment
selector to point to user-space per-cpu data. This approach performs
similarly to the getcpu cache, but it has two disadvantages: it is
not portable, and it is incompatible with existing applications already
using the gs segment selector for other purposes.
This approach is inspired by Paul Turner and Andrew Hunter's work
on percpu atomics, which lets the kernel handle restart of critical
sections. [1] [2]
Benchmarking various approaches for reading the current CPU number:
ARMv7 Processor rev 10 (v7l)
Machine model: Wandboard i.MX6 Quad Board
- Baseline (empty loop): 10.1 ns
- Read CPU from getcpu cache: 10.1 ns
- glibc 2.19-0ubuntu6.6 getcpu: 445.6 ns
- getcpu system call: 322.2 ns
x86-64 Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz:
- Baseline (empty loop): 1.0 ns
- Read CPU from getcpu cache: 1.0 ns
- Read using gs segment selector: 1.0 ns
- "lsl" inline assembly: 11.2 ns
- glibc 2.19-0ubuntu6.6 getcpu: 14.3 ns
- getcpu system call: 51.0 ns
[1] https://lwn.net/Articles/650333/
[2] http://www.linuxplumbersconf.org/2013/ocw/system/presentations/1695/original/LPC%20-%20PerCpu%20Atomics.pdf
Link: http://lkml.kernel.org/r/20151027235635.16059.11630.stgit@pjt-glaptop.roam.corp.google.com
Link: http://lkml.kernel.org/r/20150624222609.6116.86035.stgit@kitami.mtv.corp.google.com
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.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: Russell King <linux@arm.linux.org.uk>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Michael Kerrisk <mtk.manpages@gmail.com>
CC: linux-api@vger.kernel.org
---
Changes since v1:
- Return -1, errno=EINVAL if cpu_cache pointer is not aligned on
sizeof(int32_t).
- Update man page to describe the pointer alignement requirements and
update atomicity guarantees.
- Add MAINTAINERS file GETCPU_CACHE entry.
- Remove dynamic memory allocation: go back to having a single
getcpu_cache entry per thread. Update documentation accordingly.
- Rebased on Linux 4.4.
Changes since v2:
- Introduce a "cmd" argument, along with an enum with GETCPU_CACHE_GET
and GETCPU_CACHE_SET. Introduce a uapi header linux/getcpu_cache.h
defining this enumeration.
- Split resume notifier architecture implementation from the system call
wire up in the following arch-specific patches.
- Man pages updates.
- Handle 32-bit compat pointers.
- Simplify handling of getcpu_cache GETCPU_CACHE_SET compiler barrier:
set the current cpu cache pointer before doing the cache update, and
set it back to NULL if the update fails. Setting it back to NULL on
error ensures that no resume notifier will trigger a SIGSEGV if a
migration happened concurrently.
Changes since v3:
- Fix __user annotations in compat code,
- Update memory ordering comments.
- Rebased on kernel v4.5-rc5.
Rationale for the getcpu_cache system call rather than the thread-local
ABI system call proposed earlier:
Rather than doing a "generic" thread-local ABI, specialize this system
call for a cpu number cache only. Anyway, the thread-local ABI approach
would have required that we introduce "feature" flags, which would have
ended up reimplementing multiplexing of features on top of a system
call. It seems better to introduce one system call per feature instead.
Man page associated:
GETCPU_CACHE(2) Linux Programmer's Manual GETCPU_CACHE(2)
NAME
getcpu_cache - cache CPU number on which the calling thread
is running
SYNOPSIS
#include <linux/getcpu_cache.h>
#include <stdint.h>
int getcpu_cache(int cmd, int32_t **cpu_cachep, int flags);
DESCRIPTION
The getcpu_cache() helps speeding up reading the current CPU
number by ensuring that the memory location registered by
each user-space thread is always updated with the CPU number
on which the thread is running when reading that memory loca‐
tion.
The cmd argument is one of the following:
GETCPU_CACHE_GET
Get the pointer to the current cpu number cache into
the memory location targeted by the cpu_cachep
pointer.
GETCPU_CACHE_SET
Attempt to set the current cpu number cache by using
the pointer located in the memory location targeted by
the cpu_cachep pointer. This pointer must be aligned
on 4-byte multiples (natural alignment).
The cpu_cachep argument is a pointer to a int32_t pointer. It
is used as an output argument for GETCPU_CACHE_GET, and as an
input argument for GETCPU_CACHE_SET.
The flags argument is currently unused and must be specified
as 0.
Typically, a library or application will keep the cpu number
cache in a thread-local storage variable, or other memory
areas belonging to each thread. It is recommended to perform
a volatile read of the cpu number cache to prevent the com‐
piler from doing load tearing. An alternative approach is to
read the cpu number cache from inline assembly in a single
instruction.
Each thread is responsible for registering its own cpu number
cache. Only one cpu cache address can be registered per
thread.
The symbol __getcpu_cache_tls is recommended to be used
across libraries and applications wishing to register a
thread-local getcpu_cache. The attribute "weak" is recom‐
mended when declaring this variable in libraries. Applica‐
tions can choose to define their own version of this symbol
without the weak attribute as a performance improvement.
In a typical usage scenario, the thread registering the cpu
number cache will be performing reads from that cache. It is
however also allowed to read the cpu number cache from other
threads. The cpu number cache updates performed by the kernel
provide single-copy atomicity semantics, which guarantee that
other threads performing single-copy atomic reads of the cpu
number cache will always observe a consistent value.
Memory registered as cpu number cache should never be deallo‐
cated before the thread which registered it exits: specifi‐
cally, it should not be freed, and the library containing the
registered thread-local storage should not be dlclose'd.
Unregistration of associated cpu cache is implicitly per‐
formed when a thread or process exit.
RETURN VALUE
A return value of 0 indicates success. On error, -1 is
returned, and errno is set appropriately.
ERRORS
EINVAL Either flags is non-zero, an invalid cmd has been
specified, or the GETCPU_CACHE_GET command has been
specified and cpu_cachep points to a location contain‐
ing an invalid address, or cpu_cachep points to a
location containing an address which is not aligned on
4-byte multiples.
ENOSYS The getcpu_cache() system call is not implemented by
this kernel.
EFAULT cpu_cachep is an invalid address, or cpu_cachep points
to a location containing an invalid address.
EBUSY The GETCPU_CACHE_SET command has been specified, and a
cpu cache address which differs from the content of
the memory location pointed to by cpu_cachep is
already registered for this thread.
ENOENT The GETCPU_CACHE_GET command has been specified, but
no cpu cache has been registered for this thread.
VERSIONS
The getcpu_cache() system call was added in Linux 4.X (TODO).
CONFORMING TO
getcpu_cache() is Linux-specific.
EXAMPLE
The following code uses the getcpu_cache() system call to
keep a thread local storage variable up to date with the cur‐
rent CPU number, with a fallback on sched_getcpu(3) if the
cache is not available. For example simplicity, it is done in
main(), but multithreaded programs would need to invoke
getcpu_cache() from each program thread.
#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <stdint.h>
#include <sched.h>
#include <linux/getcpu_cache.h>
#include <sys/syscall.h>
static inline int
getcpu_cache(int cmd, volatile int32_t **cpu_cachep, int flags)
{
return syscall(__NR_getcpu_cache, cmd, cpu_cachep, flags);
}
/*
* __getcpu_cache_tls is recommended as symbol name for the
* cpu number cache. Weak attribute is recommended when
* declaring this variable in libraries. Applications can
* choose to define their own version of this symbol without
* the weak attribute and access it directly as a
* performance improvement when it matches the address
* returned by GETCPU_CACHE_GET. The initial value "-1"
* will be read in case the getcpu cache is not available.
*/
__thread __attribute__((weak)) volatile int32_t
__getcpu_cache_tls = -1;
int
main(int argc, char **argv)
{
volatile int32_t *cpu_cache = &__getcpu_cache_tls;
int32_t cpu;
/* Try to register the CPU cache. */
if (getcpu_cache(GETCPU_CACHE_SET, &cpu_cache, 0) < 0) {
perror("getcpu_cache set");
fprintf(stderr, "Using sched_getcpu() as fallback.\n");
}
cpu = __getcpu_cache_tls; /* Read current CPU number. */
if (cpu < 0) {
/* Fallback on sched_getcpu(). */
cpu = sched_getcpu();
}
printf("Current CPU number: %d\n", cpu);
exit(EXIT_SUCCESS);
}
SEE ALSO
sched_getcpu(3)
Linux 2016-01-27 GETCPU_CACHE(2)
---
MAINTAINERS | 7 ++
fs/exec.c | 1 +
include/linux/sched.h | 36 +++++++++
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/getcpu_cache.h | 42 ++++++++++
init/Kconfig | 10 +++
kernel/Makefile | 1 +
kernel/fork.c | 4 +
kernel/getcpu_cache.c | 163 ++++++++++++++++++++++++++++++++++++++
kernel/sched/sched.h | 1 +
kernel/sys_ni.c | 3 +
11 files changed, 269 insertions(+)
create mode 100644 include/uapi/linux/getcpu_cache.h
create mode 100644 kernel/getcpu_cache.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc1..dfef1bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4766,6 +4766,13 @@ M: Joe Perches <joe@perches.com>
S: Maintained
F: scripts/get_maintainer.pl
+GETCPU_CACHE SUPPORT
+M: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+L: linux-kernel@vger.kernel.org
+S: Supported
+F: kernel/getcpu_cache.c
+F: include/uapi/linux/getcpu_cache.h
+
GFS2 FILE SYSTEM
M: Steven Whitehouse <swhiteho@redhat.com>
M: Bob Peterson <rpeterso@redhat.com>
diff --git a/fs/exec.c b/fs/exec.c
index dcd4ac7..f4ec02f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1594,6 +1594,7 @@ static int do_execveat_common(int fd, struct filename *filename,
/* execve succeeded */
current->fs->in_exec = 0;
current->in_execve = 0;
+ getcpu_cache_execve(current);
acct_update_integrals(current);
task_numa_free(current);
free_bprm(bprm);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a10494a..18f2f79 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1830,6 +1830,9 @@ struct task_struct {
unsigned long task_state_change;
#endif
int pagefault_disabled;
+#ifdef CONFIG_GETCPU_CACHE
+ int32_t __user *cpu_cache;
+#endif
/* CPU-specific state of this task */
struct thread_struct thread;
/*
@@ -3207,4 +3210,37 @@ static inline unsigned long rlimit_max(unsigned int limit)
return task_rlimit_max(current, limit);
}
+#ifdef CONFIG_GETCPU_CACHE
+void getcpu_cache_fork(struct task_struct *t);
+void getcpu_cache_execve(struct task_struct *t);
+void getcpu_cache_exit(struct task_struct *t);
+void __getcpu_cache_handle_notify_resume(struct task_struct *t);
+static inline void getcpu_cache_set_notify_resume(struct task_struct *t)
+{
+ if (t->cpu_cache)
+ set_tsk_thread_flag(t, TIF_NOTIFY_RESUME);
+}
+static inline void getcpu_cache_handle_notify_resume(struct task_struct *t)
+{
+ if (t->cpu_cache)
+ __getcpu_cache_handle_notify_resume(t);
+}
+#else
+static inline void getcpu_cache_fork(struct task_struct *t)
+{
+}
+static inline void getcpu_cache_execve(struct task_struct *t)
+{
+}
+static inline void getcpu_cache_exit(struct task_struct *t)
+{
+}
+static inline void getcpu_cache_set_notify_resume(struct task_struct *t)
+{
+}
+static inline void getcpu_cache_handle_notify_resume(struct task_struct *t)
+{
+}
+#endif
+
#endif
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index ebd10e6..1d7eb4d 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -136,6 +136,7 @@ header-y += futex.h
header-y += gameport.h
header-y += genetlink.h
header-y += gen_stats.h
+header-y += getcpu_cache.h
header-y += gfs2_ondisk.h
header-y += gigaset_dev.h
header-y += gsmmux.h
diff --git a/include/uapi/linux/getcpu_cache.h b/include/uapi/linux/getcpu_cache.h
new file mode 100644
index 0000000..25343b9
--- /dev/null
+++ b/include/uapi/linux/getcpu_cache.h
@@ -0,0 +1,42 @@
+#ifndef _UAPI_LINUX_GETCPU_CACHE_H
+#define _UAPI_LINUX_GETCPU_CACHE_H
+
+/*
+ * linux/getcpu_cache.h
+ *
+ * getcpu_cache system call API
+ *
+ * Copyright (c) 2015, 2016 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/**
+ * enum getcpu_cache_cmd - getcpu_cache system call command
+ * @GETCPU_CACHE_GET: Get the address of the current thread CPU number
+ * cache.
+ * @GETCPU_CACHE_SET: Set the address of the current thread CPU number
+ * cache.
+ */
+enum getcpu_cache_cmd {
+ GETCPU_CACHE_GET = 0,
+ GETCPU_CACHE_SET = 1,
+};
+
+#endif /* _UAPI_LINUX_GETCPU_CACHE_H */
diff --git a/init/Kconfig b/init/Kconfig
index 2232080..e8db8db 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1589,6 +1589,16 @@ config MEMBARRIER
If unsure, say Y.
+config GETCPU_CACHE
+ bool "Enable getcpu cache" if EXPERT
+ default y
+ help
+ Enable the getcpu cache system call. It provides a user-space
+ cache for the current CPU number value, which speeds up
+ getting the current CPU number from user-space.
+
+ If unsure, say Y.
+
config EMBEDDED
bool "Embedded system"
option allnoconfig_y
diff --git a/kernel/Makefile b/kernel/Makefile
index 53abf00..b630247 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_TORTURE_TEST) += torture.o
obj-$(CONFIG_MEMBARRIER) += membarrier.o
obj-$(CONFIG_HAS_IOMEM) += memremap.o
+obj-$(CONFIG_GETCPU_CACHE) += getcpu_cache.o
$(obj)/configs.o: $(obj)/config_data.h
diff --git a/kernel/fork.c b/kernel/fork.c
index 2e391c7..fad76d5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -252,6 +252,7 @@ void __put_task_struct(struct task_struct *tsk)
WARN_ON(tsk == current);
cgroup_free(tsk);
+ getcpu_cache_exit(tsk);
task_numa_free(tsk);
security_task_free(tsk);
exit_creds(tsk);
@@ -1552,6 +1553,9 @@ static struct task_struct *copy_process(unsigned long clone_flags,
*/
copy_seccomp(p);
+ if (!(clone_flags & CLONE_THREAD))
+ getcpu_cache_fork(p);
+
/*
* Process group and session signals need to be delivered to just the
* parent before the fork or both the parent and the child after the
diff --git a/kernel/getcpu_cache.c b/kernel/getcpu_cache.c
new file mode 100644
index 0000000..b7eaed0
--- /dev/null
+++ b/kernel/getcpu_cache.c
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2015 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+ *
+ * getcpu cache system call
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/sched.h>
+#include <linux/uaccess.h>
+#include <linux/syscalls.h>
+#include <linux/compat.h>
+#include <linux/getcpu_cache.h>
+
+static int getcpu_cache_update(int32_t __user *cpu_cache)
+{
+ if (put_user(raw_smp_processor_id(), cpu_cache))
+ return -1;
+ return 0;
+}
+
+/*
+ * This resume handler should always be executed between a migration
+ * triggered by preemption and return to user-space.
+ */
+void __getcpu_cache_handle_notify_resume(struct task_struct *t)
+{
+ if (unlikely(t->flags & PF_EXITING))
+ return;
+ if (getcpu_cache_update(t->cpu_cache))
+ force_sig(SIGSEGV, t);
+}
+
+/*
+ * If parent process has a thread-local ABI, the child inherits. Only applies
+ * when forking a process, not a thread.
+ */
+void getcpu_cache_fork(struct task_struct *t)
+{
+ t->cpu_cache = current->cpu_cache;
+}
+
+void getcpu_cache_execve(struct task_struct *t)
+{
+ t->cpu_cache = NULL;
+}
+
+void getcpu_cache_exit(struct task_struct *t)
+{
+ t->cpu_cache = NULL;
+}
+
+static int __get_cpu_cache_ptr(int32_t __user **cpu_cache,
+ int32_t __user * __user *cpu_cachep)
+{
+#ifdef CONFIG_COMPAT
+ if (is_compat_task()) {
+ compat_uptr_t __user *compat_cachep =
+ (compat_uptr_t __user *) cpu_cachep;
+ compat_uptr_t compat_cache;
+
+ if (get_user(compat_cache, compat_cachep))
+ return -EFAULT;
+ *cpu_cache = compat_ptr(compat_cache);
+ return 0;
+ }
+#endif
+ return get_user(*cpu_cache, cpu_cachep);
+}
+
+#define get_cpu_cache_ptr(cpu_cache, cpu_cachep) \
+ __get_cpu_cache_ptr(&(cpu_cache), cpu_cachep)
+
+static int put_cpu_cache_ptr(int32_t __user *cpu_cache,
+ int32_t __user * __user *cpu_cachep)
+{
+#ifdef CONFIG_COMPAT
+ if (is_compat_task()) {
+ compat_uptr_t compat_cache = ptr_to_compat(cpu_cache);
+ compat_uptr_t __user *compat_cachep =
+ (compat_uptr_t __user *) cpu_cachep;
+
+ return put_user(compat_cache, compat_cachep);
+ }
+#endif
+ return put_user(cpu_cache, cpu_cachep);
+}
+
+/*
+ * sys_getcpu_cache - setup getcpu cache for caller thread
+ */
+SYSCALL_DEFINE3(getcpu_cache, int, cmd, int32_t __user * __user *, cpu_cachep,
+ int, flags)
+{
+ if (unlikely(flags))
+ return -EINVAL;
+ switch (cmd) {
+ case GETCPU_CACHE_GET:
+ if (!current->cpu_cache)
+ return -ENOENT;
+ if (put_cpu_cache_ptr(current->cpu_cache, cpu_cachep))
+ return -EFAULT;
+ return 0;
+ case GETCPU_CACHE_SET:
+ {
+ int32_t __user *cpu_cache;
+
+ if (get_cpu_cache_ptr(cpu_cache, cpu_cachep))
+ return -EFAULT;
+ if (unlikely(!IS_ALIGNED((unsigned long)cpu_cache,
+ sizeof(int32_t)) || !cpu_cache))
+ return -EINVAL;
+ /*
+ * Check if cpu_cache is already registered, and whether
+ * the address differs from *cpu_cachep.
+ */
+ if (current->cpu_cache) {
+ if (current->cpu_cache != cpu_cache)
+ return -EBUSY;
+ return 0;
+ }
+ current->cpu_cache = cpu_cache;
+ /*
+ * Migration reads the current->cpu_cache pointer to
+ * decide whether the notify_resume flag should be set.
+ * Therefore, we need to ensure that the scheduler sees
+ * the getcpu cache pointer update before we update the
+ * getcpu cache content with the current CPU number.
+ * This ensures we don't return from the getcpu_cache
+ * system call to userspace with a wrong CPU number in
+ * the cache if preempted and migrated after the initial
+ * successful cpu cache update (below).
+ *
+ * This compiler barrier enforces ordering of the
+ * current->cpu_cache address store before update of the
+ * *cpu_cache.
+ */
+ barrier();
+ /*
+ * Do an initial cpu cache update to populate the
+ * current CPU value, and to check whether the address
+ * is valid, thus ensuring we return -EFAULT in case or
+ * invalid address rather than triggering a SIGSEGV if
+ * put_user() fails in the resume notifier.
+ */
+ if (getcpu_cache_update(cpu_cache)) {
+ current->cpu_cache = NULL;
+ return -EFAULT;
+ }
+ return 0;
+ }
+ default:
+ return -EINVAL;
+ }
+}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 10f1637..11ae33f 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -971,6 +971,7 @@ static inline void __set_task_cpu(struct task_struct *p, unsigned int cpu)
{
set_task_rq(p, cpu);
#ifdef CONFIG_SMP
+ getcpu_cache_set_notify_resume(p);
/*
* After ->cpu is set up to a new value, task_rq_lock(p, ...) can be
* successfuly executed on another CPU. We must ensure that updates of
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 2c5e3a8..7e336c0 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -250,3 +250,6 @@ cond_syscall(sys_execveat);
/* membarrier */
cond_syscall(sys_membarrier);
+
+/* thread-local ABI */
+cond_syscall(sys_getcpu_cache);
--
2.1.4
[toc] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-02-24 12:20 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r5FE7-3ID-43@gated-at.bofh.it> |
| In reply to | #1341168 |
On Tue, 23 Feb 2016, Mathieu Desnoyers wrote:
> +/*
> + * If parent process has a thread-local ABI, the child inherits. Only applies
> + * when forking a process, not a thread.
> + */
> +void getcpu_cache_fork(struct task_struct *t)
> +{
> + t->cpu_cache = current->cpu_cache;
> +}
> +
> +void getcpu_cache_execve(struct task_struct *t)
> +{
> + t->cpu_cache = NULL;
> +}
> +
> +void getcpu_cache_exit(struct task_struct *t)
> +{
> + t->cpu_cache = NULL;
> +}
That's hardly worth a function call. Please inline.
> +/*
> + * sys_getcpu_cache - setup getcpu cache for caller thread
> + */
> +SYSCALL_DEFINE3(getcpu_cache, int, cmd, int32_t __user * __user *, cpu_cachep,
> + int, flags)
> +{
> + if (unlikely(flags))
> + return -EINVAL;
New line for readability sake.
> + switch (cmd) {
> + case GETCPU_CACHE_GET:
Other than that: Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-24 18:20 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r5Lgv-7GJ-9@gated-at.bofh.it> |
| In reply to | #1341889 |
----- On Feb 24, 2016, at 6:11 AM, Thomas Gleixner tglx@linutronix.de wrote:
> On Tue, 23 Feb 2016, Mathieu Desnoyers wrote:
>> +/*
>> + * If parent process has a thread-local ABI, the child inherits. Only applies
>> + * when forking a process, not a thread.
>> + */
>> +void getcpu_cache_fork(struct task_struct *t)
>> +{
>> + t->cpu_cache = current->cpu_cache;
>> +}
>> +
>> +void getcpu_cache_execve(struct task_struct *t)
>> +{
>> + t->cpu_cache = NULL;
>> +}
>> +
>> +void getcpu_cache_exit(struct task_struct *t)
>> +{
>> + t->cpu_cache = NULL;
>> +}
>
> That's hardly worth a function call. Please inline.
>
>> +/*
>> + * sys_getcpu_cache - setup getcpu cache for caller thread
>> + */
>> +SYSCALL_DEFINE3(getcpu_cache, int, cmd, int32_t __user * __user *, cpu_cachep,
>> + int, flags)
>> +{
>> + if (unlikely(flags))
>> + return -EINVAL;
>
> New line for readability sake.
>
>> + switch (cmd) {
>> + case GETCPU_CACHE_GET:
>
> Other than that: Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Thanks! Will do those changes for v5 and add your Reviewed-by tag.
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | Rasmus Villemoes <linux@rasmusvillemoes.dk> |
|---|---|
| Date | 2016-02-26 00:40 +0100 |
| Message-ID | <r6dFM-2OI-9@gated-at.bofh.it> |
| In reply to | #1341889 |
On Wed, Feb 24 2016, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > Typically, a library or application will keep the cpu number > cache in a thread-local storage variable, or other memory > areas belonging to each thread. It is recommended to perform > a volatile read of the cpu number cache to prevent the com‐ > piler from doing load tearing. An alternative approach is to > read the cpu number cache from inline assembly in a single > instruction. > > Each thread is responsible for registering its own cpu number > cache. Only one cpu cache address can be registered per > thread. > > The symbol __getcpu_cache_tls is recommended to be used > across libraries and applications wishing to register a > thread-local getcpu_cache. The attribute "weak" is recom‐ > mended when declaring this variable in libraries. Applica‐ > tions can choose to define their own version of this symbol > without the weak attribute as a performance improvement. > > In a typical usage scenario, the thread registering the cpu > number cache will be performing reads from that cache. It is > however also allowed to read the cpu number cache from other > threads. The cpu number cache updates performed by the kernel > provide single-copy atomicity semantics, which guarantee that > other threads performing single-copy atomic reads of the cpu > number cache will always observe a consistent value. > > Memory registered as cpu number cache should never be deallo‐ > cated before the thread which registered it exits: specifi‐ > cally, it should not be freed, and the library containing the > registered thread-local storage should not be dlclose'd. Maybe spell out the consequence if this is violated - since the SIGSEGV only happens on migration, it may take a while to strike. Random thoughts: The current implementation ensures that getcpu_cache is "idempotent" from within a single thread - once set, it can never get unset nor set to some other pointer. I think that can be useful, since it means a library can reliably use the TLS variable itself (initialized with some negative number) as an indicator of whether getcpu_cache(GETCPU_CACHE_SET) has been called. So if a single test on a fast path where the library would need to load __getcpu_cache_tls anyway is acceptable, it can avoid requiring some library init function to be called in each thread - which can sometimes be hard to arrange. Is this something we want to guarantee - that is, will we never implement GETCPU_CACHE_UNSET or a "force" flag to _SET? Either way, I think we should spend a few words on it to avoid the current behaviour becoming accidental ABI. In another thread: > However, there are other use-cases for having a fast mechanism for > reading the current CPU number, besides restartable sequences. For > instance, it can be used by glibc to implement a faster sched_getcpu. Will glibc do that? It may be a little contentious for glibc to claim a unique resource such as task_struct::cpu_cache for itself, even if everybody is supposed to use the same symbol. Hm, maybe one could say that if an application does define the symbol __getcpu_cache_tls (which is techically in the implementation namespace), that gives glibc (and any other library) license to do getcpu_cache(SET, &&__getcpu_cache_tls) (pseudo-code, of course). If a library initializes its own weak version with -2 it can check whether the application defined __getcpu_cache_tls. Ok, I'm probably overthinking this... Rasmus
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-26 18:50 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6uGC-6KV-15@gated-at.bofh.it> |
| In reply to | #1343581 |
----- On Feb 25, 2016, at 6:32 PM, Rasmus Villemoes linux@rasmusvillemoes.dk wrote:
> On Wed, Feb 24 2016, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>
>>
>> Typically, a library or application will keep the cpu number
>> cache in a thread-local storage variable, or other memory
>> areas belonging to each thread. It is recommended to perform
>> a volatile read of the cpu number cache to prevent the com‐
>> piler from doing load tearing. An alternative approach is to
>> read the cpu number cache from inline assembly in a single
>> instruction.
>>
>> Each thread is responsible for registering its own cpu number
>> cache. Only one cpu cache address can be registered per
>> thread.
>>
>> The symbol __getcpu_cache_tls is recommended to be used
>> across libraries and applications wishing to register a
>> thread-local getcpu_cache. The attribute "weak" is recom‐
>> mended when declaring this variable in libraries. Applica‐
>> tions can choose to define their own version of this symbol
>> without the weak attribute as a performance improvement.
>>
>> In a typical usage scenario, the thread registering the cpu
>> number cache will be performing reads from that cache. It is
>> however also allowed to read the cpu number cache from other
>> threads. The cpu number cache updates performed by the kernel
>> provide single-copy atomicity semantics, which guarantee that
>> other threads performing single-copy atomic reads of the cpu
>> number cache will always observe a consistent value.
>>
>> Memory registered as cpu number cache should never be deallo‐
>> cated before the thread which registered it exits: specifi‐
>> cally, it should not be freed, and the library containing the
>> registered thread-local storage should not be dlclose'd.
>
> Maybe spell out the consequence if this is violated - since the SIGSEGV
> only happens on migration, it may take a while to strike.
Good point.
>
> Random thoughts: The current implementation ensures that getcpu_cache is
> "idempotent" from within a single thread - once set, it can never get
> unset nor set to some other pointer. I think that can be useful, since
> it means a library can reliably use the TLS variable itself (initialized
> with some negative number) as an indicator of whether
> getcpu_cache(GETCPU_CACHE_SET) has been called. So if a single test on a
> fast path where the library would need to load __getcpu_cache_tls anyway
> is acceptable, it can avoid requiring some library init function to be
> called in each thread - which can sometimes be hard to arrange. Is this
> something we want to guarantee - that is, will we never implement
> GETCPU_CACHE_UNSET or a "force" flag to _SET? Either way, I think we
> should spend a few words on it to avoid the current behaviour becoming
> accidental ABI.
Yes, I would be tempted to state that once set, the address is idempotent
for a thread.
>
> In another thread:
>
>> However, there are other use-cases for having a fast mechanism for
>> reading the current CPU number, besides restartable sequences. For
>> instance, it can be used by glibc to implement a faster sched_getcpu.
>
> Will glibc do that? It may be a little contentious for glibc to claim a
> unique resource such as task_struct::cpu_cache for itself, even if
> everybody is supposed to use the same symbol. Hm, maybe one could say
> that if an application does define the symbol __getcpu_cache_tls (which
> is techically in the implementation namespace), that gives glibc (and
> any other library) license to do getcpu_cache(SET, &&__getcpu_cache_tls)
> (pseudo-code, of course). If a library initializes its own weak version
> with -2 it can check whether the application defined
> __getcpu_cache_tls. Ok, I'm probably overthinking this...
I've had the exact same thoughts a few days ago then thinking about
how lttng-ust could do a "lazy binding" of the getcpu_cache without
requiring an explicit initialization at thread start. We're reaching
very similar conclusions. We could recommend/require that userspace
does this whenever it defines a __getcpu_cache_tls:
Declare as
__thread __attribute__((weak)) volatile int32_t __getcpu_cache_tls = -1;
Then whenever it loads it, "-1" would mean "uninitialized", and "-2"
could mean "this thread tried to initialize it, but fail, so you
should directly go to a fallback". ">= 0" would mean initialized and
working.
static inline int32_t getcpu_cache_read(void)
{
int32_t cachev = __getcpu_cache_tls;
if (likely(cachev >= 0))
return cachev;
if (cachev == -1) {
volatile int32_t *cpu_cache = &__getcpu_cache_tls;
if (!getcpu_cache(GETCPU_CACHE_SET, &cpu_cache, 0))
return __getcpu_cache_tls;
__getcpu_cache_tls = -2;
}
/* Fallback on sched_getcpu(). */
return sched_getcpu();
}
This could be documented in the getcpu_cache system call man page.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-02-25 11:00 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r60Sg-1Sg-47@gated-at.bofh.it> |
| In reply to | #1341168 |
On Tue, Feb 23, 2016 at 06:28:36PM -0500, Mathieu Desnoyers wrote: > This approach is inspired by Paul Turner and Andrew Hunter's work > on percpu atomics, which lets the kernel handle restart of critical > sections. [1] [2] So I'd like a few extra words on the intersection with that work. Yes, that also needs a CPU number, but that needs a little extra as well. Can this work be extended to provide the little extra and is the getcpu name still sane in that case? Alternatively, could you not, at equal speed, get the CPU number from the restartable sequence data? That is, do explain why we want both. (And remind Paul to keep pushing that)
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-25 18:00 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r67qH-6DX-25@gated-at.bofh.it> |
| In reply to | #1343059 |
----- On Feb 25, 2016, at 4:56 AM, Peter Zijlstra peterz@infradead.org wrote: > On Tue, Feb 23, 2016 at 06:28:36PM -0500, Mathieu Desnoyers wrote: >> This approach is inspired by Paul Turner and Andrew Hunter's work >> on percpu atomics, which lets the kernel handle restart of critical >> sections. [1] [2] > > So I'd like a few extra words on the intersection with that work. > > Yes, that also needs a CPU number, but that needs a little extra as > well. Can this work be extended to provide the little extra and is the > getcpu name still sane in that case? > > Alternatively, could you not, at equal speed, get the CPU number from > the restartable sequence data? > > That is, do explain why we want both. Paul Turner's percpu atomics (restartable sequences) allow turning atomic instructions (e.g. LOCK; cmpxchg on x86) meant to update userspace per-cpu data into a sequence of instructions that end with a single commit instruction. The primary use-case for this is for implementing efficient memory allocators with per-cpu memory pools (rather than global or per-thread pools). This is made possible with the collaboration between kernel and user-space, where user-space marks the surrounding of this "rseq" critical section, and the kernel moves the instruction pointer to a restart address (also published by user-space) if it preempts/migrates/delivers a signal over that critical section. The benefit of those restartable sequences over atomic instructions is that it is much faster to execute a sequence of simple non-atomic instructions (e.g. load, test, cond. branch, store) than a single atomic instruction. The restartable sequences are intrinsically designed to work on per-cpu data, so they need to fetch the current CPU number within the rseq critical section. This is where the getcpu_cache system call becomes very useful when combined with rseq: getcpu_cache allows reading the current CPU number in a fraction of cycle. However, there are other use-cases for having a fast mechanism for reading the current CPU number, besides restartable sequences. For instance, it can be used by glibc to implement a faster sched_getcpu. Therefore, implementing getcpu_cache as its own system call makes sense: an architecture could very well just introduce getcpu_cache even if it cannot support restartable sequences for some reason. Also, a kernel configuration can enable getcpu_cache (since it has no effect on the scheduler switch time, only migration) without enabling restartable sequences. The main reason why I decided to start working on getcpu_cache is because I noticed that the restartable sequences system call originally proposed by Paul Turner was trying to accomplish too much at once: both handling of restartable sequences, and quickly reading the current CPU number. My thinking is that the issue of reading the current CPU number could be completely taken out of the rseq picture by having rseq rely on the address registered by getcpu_cache to read the CPU number. This would therefore simplify the implementation of rseq, and allow us to focus the rseq review discussions without being side-tracked on the simpler problem of quickly reading the current CPU number. > > (And remind Paul to keep pushing that) Indeed, I look forward to Paul's feedback on my review of his last patchset round. Hopefully this getcpu_cache work will allow us to better focus the discussions on rseq work. Is the explanation above OK for you ? I'll add it to the Changelog in v5 of the getcpu_cache series if so. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-02-25 18:10 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r67An-6XN-31@gated-at.bofh.it> |
| In reply to | #1343318 |
On Thu, Feb 25, 2016 at 04:55:26PM +0000, Mathieu Desnoyers wrote: > ----- On Feb 25, 2016, at 4:56 AM, Peter Zijlstra peterz@infradead.org wrote: > The restartable sequences are intrinsically designed to work > on per-cpu data, so they need to fetch the current CPU number > within the rseq critical section. This is where the getcpu_cache > system call becomes very useful when combined with rseq: > getcpu_cache allows reading the current CPU number in a > fraction of cycle. Yes yes, I know how restartable sequences work. But what I worry about is that they want a cpu number and a sequence number, and for performance it would be very good if those live in the same cacheline. That means either getcpu needs to grow a seq number, or restartable sequences need to _also_ provide the cpu number.
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-25 18:20 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r67K2-71c-15@gated-at.bofh.it> |
| In reply to | #1343330 |
----- On Feb 25, 2016, at 12:04 PM, Peter Zijlstra peterz@infradead.org wrote: > On Thu, Feb 25, 2016 at 04:55:26PM +0000, Mathieu Desnoyers wrote: >> ----- On Feb 25, 2016, at 4:56 AM, Peter Zijlstra peterz@infradead.org wrote: >> The restartable sequences are intrinsically designed to work >> on per-cpu data, so they need to fetch the current CPU number >> within the rseq critical section. This is where the getcpu_cache >> system call becomes very useful when combined with rseq: >> getcpu_cache allows reading the current CPU number in a >> fraction of cycle. > > Yes yes, I know how restartable sequences work. > > But what I worry about is that they want a cpu number and a sequence > number, and for performance it would be very good if those live in the > same cacheline. > > That means either getcpu needs to grow a seq number, or restartable > sequences need to _also_ provide the cpu number. If we plan things well, we could have both the cpu number and the seqnum in the same cache line, registered by two different system calls. It's up to user-space to organize those two variables to fit within the same cache-line. getcpu_cache GETCPU_CACHE_SET operation takes the address where the CPU number should live as input. rseq system call could do the same for the seqnum address. The question becomes: how do we introduce this to user-space, considering that only a single address per thread is allowed for each of getcpu_cache and rseq ? If both CPU number and seqnum are centralized in a TLS within e.g. glibc, that would be OK, but if we intend to allow libraries or applications to directly register their own getcpu_cache address and/or rseq, we may end up in situations where we have to fallback on using two different cache-lines. But how much should we care about performance in cases where non-generic libraries directly use those system calls ? Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-02-26 12:40 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6oUy-2x3-17@gated-at.bofh.it> |
| In reply to | #1343336 |
On Thu, Feb 25, 2016 at 05:17:51PM +0000, Mathieu Desnoyers wrote: > ----- On Feb 25, 2016, at 12:04 PM, Peter Zijlstra peterz@infradead.org wrote: > > > On Thu, Feb 25, 2016 at 04:55:26PM +0000, Mathieu Desnoyers wrote: > >> ----- On Feb 25, 2016, at 4:56 AM, Peter Zijlstra peterz@infradead.org wrote: > >> The restartable sequences are intrinsically designed to work > >> on per-cpu data, so they need to fetch the current CPU number > >> within the rseq critical section. This is where the getcpu_cache > >> system call becomes very useful when combined with rseq: > >> getcpu_cache allows reading the current CPU number in a > >> fraction of cycle. > > > > Yes yes, I know how restartable sequences work. > > > > But what I worry about is that they want a cpu number and a sequence > > number, and for performance it would be very good if those live in the > > same cacheline. > > > > That means either getcpu needs to grow a seq number, or restartable > > sequences need to _also_ provide the cpu number. > > If we plan things well, we could have both the cpu number and the > seqnum in the same cache line, registered by two different system > calls. It's up to user-space to organize those two variables > to fit within the same cache-line. I feel this is more fragile than needed. Why not do a single systemcall that does both? > getcpu_cache GETCPU_CACHE_SET operation takes the address where > the CPU number should live as input. > > rseq system call could do the same for the seqnum address. So I really don't like that, that means we have to track more kernel state -- we have to carry two pointers instead of one, we have to have more update functions etc.. That just increases the total overhead of all of this. > The question becomes: how do we introduce this to user-space, > considering that only a single address per thread is allowed > for each of getcpu_cache and rseq ? > > If both CPU number and seqnum are centralized in a TLS within > e.g. glibc, that would be OK, but if we intend to allow libraries > or applications to directly register their own getcpu_cache > address and/or rseq, we may end up in situations where we have > to fallback on using two different cache-lines. But how much > should we care about performance in cases where non-generic > libraries directly use those system calls ? > > Thoughts ? Yeah, not sure, but that is a separate problem. Both your proposed code and the rseq code have this. Having them separate system calls just increases the amount of ways you can do it wrong.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-02-26 17:40 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6tAS-640-25@gated-at.bofh.it> |
| In reply to | #1344186 |
On Fri, 26 Feb 2016, Peter Zijlstra wrote: > On Thu, Feb 25, 2016 at 05:17:51PM +0000, Mathieu Desnoyers wrote: > > ----- On Feb 25, 2016, at 12:04 PM, Peter Zijlstra peterz@infradead.org wrote: > > > > > On Thu, Feb 25, 2016 at 04:55:26PM +0000, Mathieu Desnoyers wrote: > > >> ----- On Feb 25, 2016, at 4:56 AM, Peter Zijlstra peterz@infradead.org wrote: > > >> The restartable sequences are intrinsically designed to work > > >> on per-cpu data, so they need to fetch the current CPU number > > >> within the rseq critical section. This is where the getcpu_cache > > >> system call becomes very useful when combined with rseq: > > >> getcpu_cache allows reading the current CPU number in a > > >> fraction of cycle. > > > > > > Yes yes, I know how restartable sequences work. > > > > > > But what I worry about is that they want a cpu number and a sequence > > > number, and for performance it would be very good if those live in the > > > same cacheline. > > > > > > That means either getcpu needs to grow a seq number, or restartable > > > sequences need to _also_ provide the cpu number. > > > > If we plan things well, we could have both the cpu number and the > > seqnum in the same cache line, registered by two different system > > calls. It's up to user-space to organize those two variables > > to fit within the same cache-line. > > I feel this is more fragile than needed. Why not do a single systemcall > that does both? Right. There is no point in having two calls and two update mechanisms for a very similar purpose. So let userspace have one struct where cpu/seq and whatever is required for rseq is located and flag at register time which parts of the struct need to be updated. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-26 18:30 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6unf-6CY-1@gated-at.bofh.it> |
| In reply to | #1344431 |
----- On Feb 26, 2016, at 11:29 AM, Thomas Gleixner tglx@linutronix.de wrote:
> On Fri, 26 Feb 2016, Peter Zijlstra wrote:
>> On Thu, Feb 25, 2016 at 05:17:51PM +0000, Mathieu Desnoyers wrote:
>> > ----- On Feb 25, 2016, at 12:04 PM, Peter Zijlstra peterz@infradead.org wrote:
>> >
>> > > On Thu, Feb 25, 2016 at 04:55:26PM +0000, Mathieu Desnoyers wrote:
>> > >> ----- On Feb 25, 2016, at 4:56 AM, Peter Zijlstra peterz@infradead.org wrote:
>> > >> The restartable sequences are intrinsically designed to work
>> > >> on per-cpu data, so they need to fetch the current CPU number
>> > >> within the rseq critical section. This is where the getcpu_cache
>> > >> system call becomes very useful when combined with rseq:
>> > >> getcpu_cache allows reading the current CPU number in a
>> > >> fraction of cycle.
>> > >
>> > > Yes yes, I know how restartable sequences work.
>> > >
>> > > But what I worry about is that they want a cpu number and a sequence
>> > > number, and for performance it would be very good if those live in the
>> > > same cacheline.
>> > >
>> > > That means either getcpu needs to grow a seq number, or restartable
>> > > sequences need to _also_ provide the cpu number.
>> >
>> > If we plan things well, we could have both the cpu number and the
>> > seqnum in the same cache line, registered by two different system
>> > calls. It's up to user-space to organize those two variables
>> > to fit within the same cache-line.
>>
>> I feel this is more fragile than needed. Why not do a single systemcall
>> that does both?
>
> Right. There is no point in having two calls and two update mechanisms for a
> very similar purpose.
>
> So let userspace have one struct where cpu/seq and whatever is required for
> rseq is located and flag at register time which parts of the struct need to be
> updated.
If we put both cpu/seq/other in that structure, why not plan ahead and make
it extensible then ?
That looks very much like the "Thread-local ABI" series I posted last year.
See https://lkml.org/lkml/2015/12/22/464
Here is why I ended up introducing the specialized "getcpu_cache" system call
rather than the "generic" system call (quote from the getcpu_cache changelog):
Rationale for the getcpu_cache system call rather than the thread-local
ABI system call proposed earlier:
Rather than doing a "generic" thread-local ABI, specialize this system
call for a cpu number cache only. Anyway, the thread-local ABI approach
would have required that we introduce "feature" flags, which would have
ended up reimplementing multiplexing of features on top of a system
call. It seems better to introduce one system call per feature instead.
If everyone end up preferring that we introduce a system call that implements
many features at once, that's indeed something we can do, but I remember
being told in the past that this is generally a bad idea.
For one thing, it would make the interface more cumbersome to deal with
from user-space in terms of feature detection: if we want to make this
interface extensible, in addition to check -1, errno=ENOSYS, userspace
would have to deal with a field containing the length of the structure
as expected by user-space and kernel, and feature flags to see the common
set of features supported by kernel and user-space.
Having one system call per feature seems simpler to handle in terms of
feature availability detection from a userspace point of view.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-02-26 19:10 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6uZY-7bk-13@gated-at.bofh.it> |
| In reply to | #1344479 |
On Fri, 26 Feb 2016, Mathieu Desnoyers wrote: > ----- On Feb 26, 2016, at 11:29 AM, Thomas Gleixner tglx@linutronix.de wrote: > > Right. There is no point in having two calls and two update mechanisms for a > > very similar purpose. > > > > So let userspace have one struct where cpu/seq and whatever is required for > > rseq is located and flag at register time which parts of the struct need to be > > updated. > > If we put both cpu/seq/other in that structure, why not plan ahead and make > it extensible then ? > > That looks very much like the "Thread-local ABI" series I posted last year. > See https://lkml.org/lkml/2015/12/22/464 > > Here is why I ended up introducing the specialized "getcpu_cache" system call > rather than the "generic" system call (quote from the getcpu_cache changelog): > > Rationale for the getcpu_cache system call rather than the thread-local > ABI system call proposed earlier: > > Rather than doing a "generic" thread-local ABI, specialize this system > call for a cpu number cache only. Anyway, the thread-local ABI approach > would have required that we introduce "feature" flags, which would have > ended up reimplementing multiplexing of features on top of a system > call. It seems better to introduce one system call per feature instead. > > If everyone end up preferring that we introduce a system call that implements > many features at once, that's indeed something we can do, but I remember > being told in the past that this is generally a bad idea. It's a bad idea if you mix stuff which does not belong together, but if you have stuff which shares a substantial amount of things then it makes a lot of sense. Especially if it adds similar stuff into hotpathes. > For one thing, it would make the interface more cumbersome to deal with > from user-space in terms of feature detection: if we want to make this > interface extensible, in addition to check -1, errno=ENOSYS, userspace > would have to deal with a field containing the length of the structure > as expected by user-space and kernel, and feature flags to see the common > set of features supported by kernel and user-space. > > Having one system call per feature seems simpler to handle in terms of > feature availability detection from a userspace point of view. That might well be, but that does not justify two fastpath updates, two seperate pointers to handle, etc .... Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-26 21:30 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6xbs-aO-15@gated-at.bofh.it> |
| In reply to | #1344522 |
----- On Feb 26, 2016, at 1:01 PM, Thomas Gleixner tglx@linutronix.de wrote: > On Fri, 26 Feb 2016, Mathieu Desnoyers wrote: >> ----- On Feb 26, 2016, at 11:29 AM, Thomas Gleixner tglx@linutronix.de wrote: >> > Right. There is no point in having two calls and two update mechanisms for a >> > very similar purpose. >> > >> > So let userspace have one struct where cpu/seq and whatever is required for >> > rseq is located and flag at register time which parts of the struct need to be >> > updated. >> >> If we put both cpu/seq/other in that structure, why not plan ahead and make >> it extensible then ? >> >> That looks very much like the "Thread-local ABI" series I posted last year. >> See https://lkml.org/lkml/2015/12/22/464 >> >> Here is why I ended up introducing the specialized "getcpu_cache" system call >> rather than the "generic" system call (quote from the getcpu_cache changelog): >> >> Rationale for the getcpu_cache system call rather than the thread-local >> ABI system call proposed earlier: >> >> Rather than doing a "generic" thread-local ABI, specialize this system >> call for a cpu number cache only. Anyway, the thread-local ABI approach >> would have required that we introduce "feature" flags, which would have >> ended up reimplementing multiplexing of features on top of a system >> call. It seems better to introduce one system call per feature instead. >> >> If everyone end up preferring that we introduce a system call that implements >> many features at once, that's indeed something we can do, but I remember >> being told in the past that this is generally a bad idea. > > It's a bad idea if you mix stuff which does not belong together, but if you > have stuff which shares a substantial amount of things then it makes a lot of > sense. Especially if it adds similar stuff into hotpathes. > >> For one thing, it would make the interface more cumbersome to deal with >> from user-space in terms of feature detection: if we want to make this >> interface extensible, in addition to check -1, errno=ENOSYS, userspace >> would have to deal with a field containing the length of the structure >> as expected by user-space and kernel, and feature flags to see the common >> set of features supported by kernel and user-space. >> >> Having one system call per feature seems simpler to handle in terms of >> feature availability detection from a userspace point of view. > > That might well be, but that does not justify two fastpath updates, two > seperate pointers to handle, etc .... Keeping two separate pointers in the task_struct rather than a single one might indeed be unwelcome, but I'm not sure I fully grasp the fast path argument in this case: getcpu_cache only sets a notifier thread flag on thread migration, whereas AFAIU rseq adds code to context switch and signal delivery, which are prone to have a higher impact. Indeed both will have their own code in the resume notifier, but is it really a fast path ? From my point of view, making it easy for userspace to just enable getcpu_cache without having the scheduler and signal delivery fast-path overhead of rseq seems like a good thing. I'm not all that sure that saving an extra pointer in task_struct justifies the added system call interface complexity. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2016-02-27 00:10 +0100 |
| Message-ID | <r6zGh-22W-5@gated-at.bofh.it> |
| In reply to | #1344656 |
On February 26, 2016 12:24:15 PM PST, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: >----- On Feb 26, 2016, at 1:01 PM, Thomas Gleixner tglx@linutronix.de >wrote: > >> On Fri, 26 Feb 2016, Mathieu Desnoyers wrote: >>> ----- On Feb 26, 2016, at 11:29 AM, Thomas Gleixner >tglx@linutronix.de wrote: >>> > Right. There is no point in having two calls and two update >mechanisms for a >>> > very similar purpose. >>> > >>> > So let userspace have one struct where cpu/seq and whatever is >required for >>> > rseq is located and flag at register time which parts of the >struct need to be >>> > updated. >>> >>> If we put both cpu/seq/other in that structure, why not plan ahead >and make >>> it extensible then ? >>> >>> That looks very much like the "Thread-local ABI" series I posted >last year. >>> See https://lkml.org/lkml/2015/12/22/464 >>> >>> Here is why I ended up introducing the specialized "getcpu_cache" >system call >>> rather than the "generic" system call (quote from the getcpu_cache >changelog): >>> >>> Rationale for the getcpu_cache system call rather than the >thread-local >>> ABI system call proposed earlier: >>> >>> Rather than doing a "generic" thread-local ABI, specialize this >system >>> call for a cpu number cache only. Anyway, the thread-local ABI >approach >>> would have required that we introduce "feature" flags, which >would have >>> ended up reimplementing multiplexing of features on top of a >system >>> call. It seems better to introduce one system call per feature >instead. >>> >>> If everyone end up preferring that we introduce a system call that >implements >>> many features at once, that's indeed something we can do, but I >remember >>> being told in the past that this is generally a bad idea. >> >> It's a bad idea if you mix stuff which does not belong together, but >if you >> have stuff which shares a substantial amount of things then it makes >a lot of >> sense. Especially if it adds similar stuff into hotpathes. >> >>> For one thing, it would make the interface more cumbersome to deal >with >>> from user-space in terms of feature detection: if we want to make >this >>> interface extensible, in addition to check -1, errno=ENOSYS, >userspace >>> would have to deal with a field containing the length of the >structure >>> as expected by user-space and kernel, and feature flags to see the >common >>> set of features supported by kernel and user-space. >>> >>> Having one system call per feature seems simpler to handle in terms >of >>> feature availability detection from a userspace point of view. >> >> That might well be, but that does not justify two fastpath updates, >two >> seperate pointers to handle, etc .... > >Keeping two separate pointers in the task_struct rather than a single >one >might indeed be unwelcome, but I'm not sure I fully grasp the fast path >argument in this case: getcpu_cache only sets a notifier thread flag >on thread migration, whereas AFAIU rseq adds code to context switch and >signal >delivery, which are prone to have a higher impact. > >Indeed both will have their own code in the resume notifier, but is it >really >a fast path ? > >From my point of view, making it easy for userspace to just enable >getcpu_cache >without having the scheduler and signal delivery fast-path overhead of >rseq seems >like a good thing. I'm not all that sure that saving an extra pointer >in >task_struct justifies the added system call interface complexity. > >Thanks, > >Mathieu I think it would be a good idea to make this a general pointer for the kernel to be able to write per thread state to user space, which obviously can't be done with the vDSO. This means the libc per thread startup should query the kernel for the size of this structure and allocate thread local data accordingly. We can then grow this structure if needed without making the ABI even more complex. This is more than a system call: this is an entirely new way for userspace to interact with the kernel. Therefore we should make it a general facility. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-27 01:50 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6Bf4-370-15@gated-at.bofh.it> |
| In reply to | #1344811 |
----- On Feb 26, 2016, at 6:04 PM, H. Peter Anvin hpa@zytor.com wrote: > On February 26, 2016 12:24:15 PM PST, Mathieu Desnoyers > <mathieu.desnoyers@efficios.com> wrote: >>----- On Feb 26, 2016, at 1:01 PM, Thomas Gleixner tglx@linutronix.de >>wrote: >> >>> On Fri, 26 Feb 2016, Mathieu Desnoyers wrote: >>>> ----- On Feb 26, 2016, at 11:29 AM, Thomas Gleixner >>tglx@linutronix.de wrote: >>>> > Right. There is no point in having two calls and two update >>mechanisms for a >>>> > very similar purpose. >>>> > >>>> > So let userspace have one struct where cpu/seq and whatever is >>required for >>>> > rseq is located and flag at register time which parts of the >>struct need to be >>>> > updated. >>>> >>>> If we put both cpu/seq/other in that structure, why not plan ahead >>and make >>>> it extensible then ? >>>> >>>> That looks very much like the "Thread-local ABI" series I posted >>last year. >>>> See https://lkml.org/lkml/2015/12/22/464 >>>> >>>> Here is why I ended up introducing the specialized "getcpu_cache" >>system call >>>> rather than the "generic" system call (quote from the getcpu_cache >>changelog): >>>> >>>> Rationale for the getcpu_cache system call rather than the >>thread-local >>>> ABI system call proposed earlier: >>>> >>>> Rather than doing a "generic" thread-local ABI, specialize this >>system >>>> call for a cpu number cache only. Anyway, the thread-local ABI >>approach >>>> would have required that we introduce "feature" flags, which >>would have >>>> ended up reimplementing multiplexing of features on top of a >>system >>>> call. It seems better to introduce one system call per feature >>instead. >>>> >>>> If everyone end up preferring that we introduce a system call that >>implements >>>> many features at once, that's indeed something we can do, but I >>remember >>>> being told in the past that this is generally a bad idea. >>> >>> It's a bad idea if you mix stuff which does not belong together, but >>if you >>> have stuff which shares a substantial amount of things then it makes >>a lot of >>> sense. Especially if it adds similar stuff into hotpathes. >>> >>>> For one thing, it would make the interface more cumbersome to deal >>with >>>> from user-space in terms of feature detection: if we want to make >>this >>>> interface extensible, in addition to check -1, errno=ENOSYS, >>userspace >>>> would have to deal with a field containing the length of the >>structure >>>> as expected by user-space and kernel, and feature flags to see the >>common >>>> set of features supported by kernel and user-space. >>>> >>>> Having one system call per feature seems simpler to handle in terms >>of >>>> feature availability detection from a userspace point of view. >>> >>> That might well be, but that does not justify two fastpath updates, >>two >>> seperate pointers to handle, etc .... >> >>Keeping two separate pointers in the task_struct rather than a single >>one >>might indeed be unwelcome, but I'm not sure I fully grasp the fast path >>argument in this case: getcpu_cache only sets a notifier thread flag >>on thread migration, whereas AFAIU rseq adds code to context switch and >>signal >>delivery, which are prone to have a higher impact. >> >>Indeed both will have their own code in the resume notifier, but is it >>really >>a fast path ? >> >>From my point of view, making it easy for userspace to just enable >>getcpu_cache >>without having the scheduler and signal delivery fast-path overhead of >>rseq seems >>like a good thing. I'm not all that sure that saving an extra pointer >>in >>task_struct justifies the added system call interface complexity. >> >>Thanks, >> >>Mathieu > > I think it would be a good idea to make this a general pointer for the kernel to > be able to write per thread state to user space, which obviously can't be done > with the vDSO. > > This means the libc per thread startup should query the kernel for the size of > this structure and allocate thread local data accordingly. We can then grow > this structure if needed without making the ABI even more complex. > > This is more than a system call: this is an entirely new way for userspace to > interact with the kernel. Therefore we should make it a general facility. I'm really glad to see I'm not the only one seeing potential for genericity here. :-) This is exactly what I had in mind last year when proposing the thread_local_abi() system call: a generic way to register an extensible per-thread data structure so the kernel can communicate with user-space and vice-versa. Rather than having the libc query the kernel for size of the structure, I would recommend that libc tells the kernel the size of the thread-local ABI structure it supports. The idea here is that both the kernel and libc need to know about the fields in that structure to allow a two-way interaction. Fields known only by either the kernel or userspace are useless for a given thread anyway. This way, libc could statically define the structure. I would be tempted to also add "features" flags, so both user-space and the kernel could tell each other what they support: user-space would announce the set of features it supports, and it could also query the kernel for the set of supported features. One simple approach would be to use a uint64_t as type for those feature flags, and reserve the last bit for extending to future flags if we ever have more than 64. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2016-02-27 07:30 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6Gy5-7hl-3@gated-at.bofh.it> |
| In reply to | #1344873 |
On 02/26/16 16:40, Mathieu Desnoyers wrote: >> >> I think it would be a good idea to make this a general pointer for the kernel to >> be able to write per thread state to user space, which obviously can't be done >> with the vDSO. >> >> This means the libc per thread startup should query the kernel for the size of >> this structure and allocate thread local data accordingly. We can then grow >> this structure if needed without making the ABI even more complex. >> >> This is more than a system call: this is an entirely new way for userspace to >> interact with the kernel. Therefore we should make it a general facility. > > I'm really glad to see I'm not the only one seeing potential for > genericity here. :-) This is exactly what I had in mind > last year when proposing the thread_local_abi() system call: > a generic way to register an extensible per-thread data structure > so the kernel can communicate with user-space and vice-versa. > > Rather than having the libc query the kernel for size of the structure, > I would recommend that libc tells the kernel the size of the thread-local > ABI structure it supports. The idea here is that both the kernel and libc > need to know about the fields in that structure to allow a two-way > interaction. Fields known only by either the kernel or userspace > are useless for a given thread anyway. This way, libc could statically > define the structure. Big fat NOPE there. Why? Because it means that EVERY interaction with this memory, no matter how critical, needs to be conditionalized. Furthermore, userspace != libc. Applications or higher-layer libraries might have more information than the running libc about additional fields, but with your proposal libc would gate them. As far as the kernel providing the size in the structure (alone) -- I *really* hope you can see what is wrong with that!! That doesn't mean we can't provide it in the structure as well, and that too might avoid the skipped libc problem. > I would be tempted to also add "features" flags, so both user-space > and the kernel could tell each other what they support: user-space > would announce the set of features it supports, and it could also > query the kernel for the set of supported features. One simple approach > would be to use a uint64_t as type for those feature flags, and > reserve the last bit for extending to future flags if we ever have > more than 64. > > Thoughts ? It doesn't seem like it would hurt, although the size of the flags field could end up being an issue. -hpa
[toc] | [prev] | [next] | [standalone]
| From | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| Date | 2016-02-27 15:20 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6NSW-4fA-5@gated-at.bofh.it> |
| In reply to | #1344924 |
----- On Feb 27, 2016, at 1:24 AM, H. Peter Anvin hpa@zytor.com wrote:
> On 02/26/16 16:40, Mathieu Desnoyers wrote:
>>>
>>> I think it would be a good idea to make this a general pointer for the kernel to
>>> be able to write per thread state to user space, which obviously can't be done
>>> with the vDSO.
>>>
>>> This means the libc per thread startup should query the kernel for the size of
>>> this structure and allocate thread local data accordingly. We can then grow
>>> this structure if needed without making the ABI even more complex.
>>>
>>> This is more than a system call: this is an entirely new way for userspace to
>>> interact with the kernel. Therefore we should make it a general facility.
>>
>> I'm really glad to see I'm not the only one seeing potential for
>> genericity here. :-) This is exactly what I had in mind
>> last year when proposing the thread_local_abi() system call:
>> a generic way to register an extensible per-thread data structure
>> so the kernel can communicate with user-space and vice-versa.
>>
>> Rather than having the libc query the kernel for size of the structure,
>> I would recommend that libc tells the kernel the size of the thread-local
>> ABI structure it supports. The idea here is that both the kernel and libc
>> need to know about the fields in that structure to allow a two-way
>> interaction. Fields known only by either the kernel or userspace
>> are useless for a given thread anyway. This way, libc could statically
>> define the structure.
>
> Big fat NOPE there. Why? Because it means that EVERY interaction with
> this memory, no matter how critical, needs to be conditionalized.
> Furthermore, userspace != libc. Applications or higher-layer libraries
> might have more information than the running libc about additional
> fields, but with your proposal libc would gate them.
Good point!
>
> As far as the kernel providing the size in the structure (alone) -- I
> *really* hope you can see what is wrong with that!! That doesn't mean
> we can't provide it in the structure as well, and that too might avoid
> the skipped libc problem.
Indeed, libc would need to query the size before it can allocate
the structure.
>
>> I would be tempted to also add "features" flags, so both user-space
>> and the kernel could tell each other what they support: user-space
>> would announce the set of features it supports, and it could also
>> query the kernel for the set of supported features. One simple approach
>> would be to use a uint64_t as type for those feature flags, and
>> reserve the last bit for extending to future flags if we ever have
>> more than 64.
>>
>> Thoughts ?
>
> It doesn't seem like it would hurt, although the size of the flags field
> could end up being an issue.
I'm concerned that this thread-local ABI structure may become messy.
Let's just imagine how we would first introduce a "cpu_id" field (int32_t),
and eventually add a "seqnum" field for rseq in the future (unsigned long).
Both fields need to be read with single-copy semantics as volatile
reads, and both need to be naturally aligned. However, I'm tempted
to use the "packed" attribute on the structure since it's an ABI
between kernel and user-space. A pretty bad example of what this
could become, due to alignment constraints, looks like:
/* This structure needs to be aligned on pointer size. */
struct thread_local_abi {
int32_t cpu_id;
int32_t __unused1;
unsigned long seqnum;
/* Add new fields at the end. */
} __attribute__((packed));
And this is just a start. It may become messier as we append
new fields in the future.
The main argument I currently see in favor of having this
meta system call for all per-thread features is to only
maintain a single pointer in the kernel task_struct rather
than one per thread-local feature.
If the goal is really to keep the burden on the task struct
small, we could use kmalloc()/kfree() to allocate and free an
array of pointers to the various per-thread features, rather
than putting them directly in task_struct. We could keep a
mask of the enabled features in the task struct too (which
we will likely have to do even if we go the the thread-local
ABI meta system call).
Having this per-task allocated pointer array at kernel-level
would allow us to have one system call per feature, with clear
semantics, without evolving a messy thread-local ABI structure
due to all sorts of alignment constraints.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-02-27 16:00 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6OvE-4uv-9@gated-at.bofh.it> |
| In reply to | #1345021 |
On Sat, Feb 27, 2016 at 02:15:01PM +0000, Mathieu Desnoyers wrote:
> I'm concerned that this thread-local ABI structure may become messy.
> Let's just imagine how we would first introduce a "cpu_id" field (int32_t),
> and eventually add a "seqnum" field for rseq in the future (unsigned long).
The rseq seq number can be uint32_t, in fact it is in Paul's patches.
(This is true because every seq increment will guarantee a userspace
exception and reload of the value, its impossible to wrap the thing and
get a false positive.)
Paul's patches have the following structure:
struct thread_local_abi {
union {
struct {
u32 cpu_id;
u32 seq;
};
u64 cpu_seq;
};
unsigned long post_commit_ip;
};
Although he allows the post_commit_ip to be a separate field (which I
don't think makes sense).
> /* This structure needs to be aligned on pointer size. */
I would mandate the thing be cacheline aligned, and sod packed, that can
lead to horrible layouts.
> If the goal is really to keep the burden on the task struct
> small, we could use kmalloc()/kfree() to allocate and free an
> array of pointers to the various per-thread features, rather
*groan*, no that's even worse, then you get even more loads to update
the fields. The point is to reduce the total overhead of having this
stuff.
Having a single pointer with known offsets is best because then its
guaranteed a single load, then having the whole data structure in a
single cacheline again saves on memops, you can only miss once.
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2016-02-27 19:40 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r6RWy-76H-13@gated-at.bofh.it> |
| In reply to | #1345028 |
On Sat, Feb 27, 2016 at 6:58 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> Paul's patches have the following structure:
>
> struct thread_local_abi {
> union {
> struct {
> u32 cpu_id;
> u32 seq;
> };
> u64 cpu_seq;
> };
> unsigned long post_commit_ip;
> };
Please don't do "unsigned long" in ABI structures any more.
Make it u64, and make sure it is 64-bit aligned (which it would be in
this case). Make it so that we don't have to have separate compat
paths.
Linus
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.kernel
csiph-web