lkml.org 
[lkml]   [2016]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread
    On Wed, Jan 27, 2016 at 11:54:41AM -0500, Mathieu Desnoyers wrote:
    > 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:
    > Ref.:
    > * https://lkml.org/lkml/2015/10/27/1095
    > * https://lkml.org/lkml/2015/6/24/665
    > * https://lwn.net/Articles/650333/
    > * http://www.linuxplumbersconf.org/2013/ocw/system/presentations/1695/original/LPC%20-%20PerCpu%20Atomics.pdf
    >
    > 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
    >
    > 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: 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.

    With the dynamic allocation removed, this seems sensible to me. One
    minor nit: s/int32_t/uint32_t/g, since a location intended to hold a CPU
    number should never need to hold a negative number.

    \
     
     \ /
      Last update: 2016-01-27 18:41    [W:3.661 / U:0.244 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site