Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Sat, Aug 27, 2016 at 5:21 AM, Pavel Machek wrote: > > Hi! > >> Expose a new system call allowing each thread to register one userspace >> memory area to be used as an ABI between kernel and user-space for two >> purposes: user-space restartable sequences and quick access to read

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Sat, Aug 27, 2016 at 5:21 AM, Pavel Machek wrote: > > Hi! > >> Expose a new system call allowing each thread to register one userspace >> memory area to be used as an ABI between kernel and user-space for two >> purposes: user-space restartable sequences and quick access to read the >> current

Re: [RFC PATCH v8 1/9] Restartable sequences system call

Hi! > Expose a new system call allowing each thread to register one userspace > memory area to be used as an ABI between kernel and user-space for two > purposes: user-space restartable sequences and quick access to read the > current CPU number value from user-space. > > * Restartable

Re: [RFC PATCH v8 1/9] Restartable sequences system call

Hi! > Expose a new system call allowing each thread to register one userspace > memory area to be used as an ABI between kernel and user-space for two > purposes: user-space restartable sequences and quick access to read the > current CPU number value from user-space. > > * Restartable

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > >> rseq opens up a whole world of algorithms to userspace – algorithms > >> that

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > >> rseq opens up a whole world of algorithms to userspace – algorithms > >> that

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > Ben, Mathieu, Dave, do you have jemalloc benchmark numbers with and > > without rseq? (As well as memory usage numbers for the reduced memory > >

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > Ben, Mathieu, Dave, do you have jemalloc benchmark numbers with and > > without rseq? (As well as memory usage numbers for the reduced memory > >

Re: [RFC PATCH v8 1/9] Restartable sequences system call

- On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: >> rseq opens up a whole world of algorithms to userspace – algorithms >> that are O(num CPUs) and where one can have an extremely fast fastpath >> at the

Re: [RFC PATCH v8 1/9] Restartable sequences system call

- On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: >> rseq opens up a whole world of algorithms to userspace – algorithms >> that are O(num CPUs) and where one can have an extremely fast fastpath >> at the

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > rseq opens up a whole world of algorithms to userspace – algorithms > that are O(num CPUs) and where one can have an extremely fast fastpath > at the cost of a slower slow path. Many of these algorithms are in use > in the kernel today

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > rseq opens up a whole world of algorithms to userspace – algorithms > that are O(num CPUs) and where one can have an extremely fast fastpath > at the cost of a slower slow path. Many of these algorithms are in use > in the kernel today

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On 8/25/16, 10:08 AM, "Mathieu Desnoyers" wrote: > The most appealing application we have so far is Dave Watson's Facebook >services using jemalloc as a memory allocator. It would be nice if he >could re-run those benchmarks with my rseq implementation.

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On 8/25/16, 10:08 AM, "Mathieu Desnoyers" wrote: > The most appealing application we have so far is Dave Watson's Facebook >services using jemalloc as a memory allocator. It would be nice if he >could re-run those benchmarks with my rseq implementation. The trade-offs >here are about

Re: [RFC PATCH v8 1/9] Restartable sequences system call

- On Aug 19, 2016, at 4:23 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers > wrote: >> >> Benchmarking various approaches for reading the current CPU number: > > So I'd like to see the benchmarks

Re: [RFC PATCH v8 1/9] Restartable sequences system call

- On Aug 19, 2016, at 4:23 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers > wrote: >> >> Benchmarking various approaches for reading the current CPU number: > > So I'd like to see the benchmarks of something that actually *does*

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 02:32:13PM -0700, Linus Torvalds wrote: > On Fri, Aug 19, 2016 at 2:19 PM, Paul E. McKenney > wrote: > > On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > >> > >> malloc is the primary target I believe. Saves lots of memory to keep >

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 02:32:13PM -0700, Linus Torvalds wrote: > On Fri, Aug 19, 2016 at 2:19 PM, Paul E. McKenney > wrote: > > On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > >> > >> malloc is the primary target I believe. Saves lots of memory to keep > >> caches per CPU rather

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On 08/19/16 02:24 PM, Josh Triplett wrote: > On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > > > Nobody gets a cpu number just to get a cpu number - it's not a useful > > > thing to benchmark. What does getcpu() so much that we care? > > > > malloc is the primary target I believe.

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On 08/19/16 02:24 PM, Josh Triplett wrote: > On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > > > Nobody gets a cpu number just to get a cpu number - it's not a useful > > > thing to benchmark. What does getcpu() so much that we care? > > > > malloc is the primary target I believe.

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 2:19 PM, Paul E. McKenney wrote: > On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: >> >> malloc is the primary target I believe. Saves lots of memory to keep >> caches per CPU rather than per thread. > > Agreed, a competent default

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 2:19 PM, Paul E. McKenney wrote: > On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: >> >> malloc is the primary target I believe. Saves lots of memory to keep >> caches per CPU rather than per thread. > > Agreed, a competent default malloc() in glibc would be a

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > > Nobody gets a cpu number just to get a cpu number - it's not a useful > > thing to benchmark. What does getcpu() so much that we care? > > malloc is the primary target I believe. Saves lots of memory to keep > caches per CPU rather

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > > Nobody gets a cpu number just to get a cpu number - it's not a useful > > thing to benchmark. What does getcpu() so much that we care? > > malloc is the primary target I believe. Saves lots of memory to keep > caches per CPU rather

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > > Nobody gets a cpu number just to get a cpu number - it's not a useful > > thing to benchmark. What does getcpu() so much that we care? > > malloc is the primary target I believe. Saves lots of memory to keep > caches per CPU rather

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:56:11PM -0700, Andi Kleen wrote: > > Nobody gets a cpu number just to get a cpu number - it's not a useful > > thing to benchmark. What does getcpu() so much that we care? > > malloc is the primary target I believe. Saves lots of memory to keep > caches per CPU rather

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 1:44 PM, Josh Triplett wrote: > > The combination of CPU number and restartable sequence allows userspace > to write "per-CPU" rather than "per-thread" algorithms, just as the > kernel can. The kernel can do that with preempt_disable(). Userspace >

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 1:44 PM, Josh Triplett wrote: > > The combination of CPU number and restartable sequence allows userspace > to write "per-CPU" rather than "per-thread" algorithms, just as the > kernel can. The kernel can do that with preempt_disable(). Userspace > can do it with "tell

Re: [RFC PATCH v8 1/9] Restartable sequences system call

> Nobody gets a cpu number just to get a cpu number - it's not a useful > thing to benchmark. What does getcpu() so much that we care? malloc is the primary target I believe. Saves lots of memory to keep caches per CPU rather than per thread. -Andi

Re: [RFC PATCH v8 1/9] Restartable sequences system call

> Nobody gets a cpu number just to get a cpu number - it's not a useful > thing to benchmark. What does getcpu() so much that we care? malloc is the primary target I believe. Saves lots of memory to keep caches per CPU rather than per thread. -Andi

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:23:57PM -0700, Linus Torvalds wrote: > On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers > wrote: > > > > Benchmarking various approaches for reading the current CPU number: > > So I'd like to see the benchmarks of something that

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:23:57PM -0700, Linus Torvalds wrote: > On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers > wrote: > > > > Benchmarking various approaches for reading the current CPU number: > > So I'd like to see the benchmarks of something that actually *does* something. > > IOW,

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers wrote: > > Benchmarking various approaches for reading the current CPU number: So I'd like to see the benchmarks of something that actually *does* something. IOW, what's the bigger-picture "this is what it

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers wrote: > > Benchmarking various approaches for reading the current CPU number: So I'd like to see the benchmarks of something that actually *does* something. IOW, what's the bigger-picture "this is what it actually is useful for, and how it

[RFC PATCH v8 1/9] Restartable sequences system call

Expose a new system call allowing each thread to register one userspace memory area to be used as an ABI between kernel and user-space for two purposes: user-space restartable sequences and quick access to read the current CPU number value from user-space. * Restartable sequences (per-cpu

[RFC PATCH v8 1/9] Restartable sequences system call

Expose a new system call allowing each thread to register one userspace memory area to be used as an ABI between kernel and user-space for two purposes: user-space restartable sequences and quick access to read the current CPU number value from user-space. * Restartable sequences (per-cpu