Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 23, 2017, at 7:30 PM, Ben Maurer bmau...@fb.com wrote: >> if (!((long)ip - (long)start_ip <= (long)post_commit_offset)) >>   return 1; > >> This introduces an issue here: if "ip" is lower than "start_ip", we >> can incorrectly think we are in a critical section, when we are in >>

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 23, 2017, at 7:30 PM, Ben Maurer bmau...@fb.com wrote: >> if (!((long)ip - (long)start_ip <= (long)post_commit_offset)) >>   return 1; > >> This introduces an issue here: if "ip" is lower than "start_ip", we >> can incorrectly think we are in a critical section, when we are in >>

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> if (!((long)ip - (long)start_ip <= (long)post_commit_offset)) >   return 1; > This introduces an issue here: if "ip" is lower than "start_ip", we > can incorrectly think we are in a critical section, when we are in > fact not. This shouldn't be an issue if we used unsigned numbers. Eg if

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> if (!((long)ip - (long)start_ip <= (long)post_commit_offset)) >   return 1; > This introduces an issue here: if "ip" is lower than "start_ip", we > can incorrectly think we are in a critical section, when we are in > fact not. This shouldn't be an issue if we used unsigned numbers. Eg if

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

* Mathieu Desnoyers: > Speaking of optimization, I think the rseq.c helper library > (and eventually glibc) should define the __rseq_abi TLS > variable with __attribute__((tls_model("initial-exec"))). > It provides faster, and signal-safe, accesses to the TLS > variable from libraries. > > The

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

* Mathieu Desnoyers: > Speaking of optimization, I think the rseq.c helper library > (and eventually glibc) should define the __rseq_abi TLS > variable with __attribute__((tls_model("initial-exec"))). > It provides faster, and signal-safe, accesses to the TLS > variable from libraries. > > The

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

Speaking of optimization, I think the rseq.c helper library (and eventually glibc) should define the __rseq_abi TLS variable with __attribute__((tls_model("initial-exec"))). It provides faster, and signal-safe, accesses to the TLS variable from libraries. The idea you were suggesting where the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

Speaking of optimization, I think the rseq.c helper library (and eventually glibc) should define the __rseq_abi TLS variable with __attribute__((tls_model("initial-exec"))). It provides faster, and signal-safe, accesses to the TLS variable from libraries. The idea you were suggesting where the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 18, 2017, at 12:41 PM, Ben Maurer bmau...@fb.com wrote: >> The layout of struct rseq_cs is as follows: > >> start_ip >> Instruction pointer address of the first instruction of the >> sequence of consecutive assembly instructions. > >> post_commit_ip >> Instruction pointer address

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 18, 2017, at 12:41 PM, Ben Maurer bmau...@fb.com wrote: >> The layout of struct rseq_cs is as follows: > >> start_ip >> Instruction pointer address of the first instruction of the >> sequence of consecutive assembly instructions. > >> post_commit_ip >> Instruction pointer address

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> The layout of struct rseq_cs is as follows: > start_ip > Instruction pointer address of the first instruction of the > sequence of consecutive assembly instructions. > post_commit_ip > Instruction pointer address after the last  instruction  of >  the sequence of consecutive assembly

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> The layout of struct rseq_cs is as follows: > start_ip > Instruction pointer address of the first instruction of the > sequence of consecutive assembly instructions. > post_commit_ip > Instruction pointer address after the last  instruction  of >  the sequence of consecutive assembly

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 18, 2017, at 2:22 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: > On Tue, Oct 17, 2017 at 04:19:41PM +, Ben Maurer wrote: >> Hey, >> >> > So far the restrictions I see for libraries using this symbol are: >> > - They should never be unloaded, >> > - They should never

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 18, 2017, at 2:22 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: > On Tue, Oct 17, 2017 at 04:19:41PM +, Ben Maurer wrote: >> Hey, >> >> > So far the restrictions I see for libraries using this symbol are: >> > - They should never be unloaded, >> > - They should never

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Tue, Oct 17, 2017 at 04:19:41PM +, Ben Maurer wrote: > Hey, > > > So far the restrictions I see for libraries using this symbol are: > > - They should never be unloaded, > > - They should never be loaded with dlopen RTLD_LOCAL flag. > > We talked a bit about this off-list but I wanted to

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Tue, Oct 17, 2017 at 04:19:41PM +, Ben Maurer wrote: > Hey, > > > So far the restrictions I see for libraries using this symbol are: > > - They should never be unloaded, > > - They should never be loaded with dlopen RTLD_LOCAL flag. > > We talked a bit about this off-list but I wanted to

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 17, 2017, at 12:41 PM, Ben Maurer bmau...@fb.com wrote: >> I have a use-case for keeping the reference counting in place though. It's >> use of rseq in signal handlers. > > Would this be solved by saying that the rseq api will return an error if you > register and there's already a

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 17, 2017, at 12:41 PM, Ben Maurer bmau...@fb.com wrote: >> I have a use-case for keeping the reference counting in place though. It's >> use of rseq in signal handlers. > > Would this be solved by saying that the rseq api will return an error if you > register and there's already a

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> I have a use-case for keeping the reference counting in place though. It's > use of rseq in signal handlers. Would this be solved by saying that the rseq api will return an error if you register and there's already a block registered. In this case the signal handler would register the rseq

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> I have a use-case for keeping the reference counting in place though. It's > use of rseq in signal handlers. Would this be solved by saying that the rseq api will return an error if you register and there's already a block registered. In this case the signal handler would register the rseq

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 17, 2017, at 12:19 PM, Ben Maurer bmau...@fb.com wrote: > Hey, > >> So far the restrictions I see for libraries using this symbol are: >> - They should never be unloaded, >> - They should never be loaded with dlopen RTLD_LOCAL flag. > > We talked a bit about this off-list but I

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 17, 2017, at 12:19 PM, Ben Maurer bmau...@fb.com wrote: > Hey, > >> So far the restrictions I see for libraries using this symbol are: >> - They should never be unloaded, >> - They should never be loaded with dlopen RTLD_LOCAL flag. > > We talked a bit about this off-list but I

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

Hey, > So far the restrictions I see for libraries using this symbol are: > - They should never be unloaded, > - They should never be loaded with dlopen RTLD_LOCAL flag. We talked a bit about this off-list but I wanted to state publicly that I think this model works well for our use case.

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

Hey, > So far the restrictions I see for libraries using this symbol are: > - They should never be unloaded, > - They should never be loaded with dlopen RTLD_LOCAL flag. We talked a bit about this off-list but I wanted to state publicly that I think this model works well for our use case.

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 16, 2017, at 12:46 PM, Andi Kleen a...@firstfloor.org wrote: >> How you collect, summarize, and analyze that overwhelming evidence >> is up to you, specific to each change, and difficult to do accurately >> and with any large measure of statistical confidence. The reviewer >> has to

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 16, 2017, at 12:46 PM, Andi Kleen a...@firstfloor.org wrote: >> How you collect, summarize, and analyze that overwhelming evidence >> is up to you, specific to each change, and difficult to do accurately >> and with any large measure of statistical confidence. The reviewer >> has to

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> How you collect, summarize, and analyze that overwhelming evidence > is up to you, specific to each change, and difficult to do accurately > and with any large measure of statistical confidence. The reviewer > has to basically trust you to some degree :-) I think Linus' just asked for some

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> How you collect, summarize, and analyze that overwhelming evidence > is up to you, specific to each change, and difficult to do accurately > and with any large measure of statistical confidence. The reviewer > has to basically trust you to some degree :-) I think Linus' just asked for some

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 02:36 PM, Mathieu Desnoyers wrote: > I also spoke to Carlos O'Donell from glibc about it, and he was very > excited about the possible use of rseq for malloc speedup/memory usage > improvement. But again, I don't see a project like glibc starting to > use a system call for which the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 02:36 PM, Mathieu Desnoyers wrote: > I also spoke to Carlos O'Donell from glibc about it, and he was very > excited about the possible use of rseq for malloc speedup/memory usage > improvement. But again, I don't see a project like glibc starting to > use a system call for which the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 2:17 PM, Andy Lutomirski l...@amacapital.net wrote: > On Fri, Oct 13, 2017 at 10:53 AM, Florian Weimer wrote: >> On 10/13/2017 07:24 PM, Andy Lutomirski wrote: >>> >>> On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers >>>

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 2:17 PM, Andy Lutomirski l...@amacapital.net wrote: > On Fri, Oct 13, 2017 at 10:53 AM, Florian Weimer wrote: >> On 10/13/2017 07:24 PM, Andy Lutomirski wrote: >>> >>> On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers >>> wrote: - On Oct 13, 2017, at

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 14, 2017, at 12:05 AM, Linus Torvalds torva...@linux-foundation.org wrote: > On Fri, Oct 13, 2017 at 8:01 PM, Andi Kleen wrote: >> >> As far as I can see the current model fundamentally only works for >> one user per process (because there is only a single

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 14, 2017, at 12:05 AM, Linus Torvalds torva...@linux-foundation.org wrote: > On Fri, Oct 13, 2017 at 8:01 PM, Andi Kleen wrote: >> >> As far as I can see the current model fundamentally only works for >> one user per process (because there is only a single range and abort IP) > >

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 8:01 PM, Andi Kleen wrote: > > As far as I can see the current model fundamentally only works for > one user per process (because there is only a single range and abort IP) No, it should work for libraries, you just need to always initialize the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 8:01 PM, Andi Kleen wrote: > > As far as I can see the current model fundamentally only works for > one user per process (because there is only a single range and abort IP) No, it should work for libraries, you just need to always initialize the proper start/commit/abort

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> That sounds so obvious and stupid that you might go "What do you > mean?", but for things to work for libraries, they have to work > together with *other* users, and with *independent* users. As far as I can see the current model fundamentally only works for one user per process (because there

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

> That sounds so obvious and stupid that you might go "What do you > mean?", but for things to work for libraries, they have to work > together with *other* users, and with *independent* users. As far as I can see the current model fundamentally only works for one user per process (because there

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 5:05 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Fri, Oct 13, 2017 at 1:54 PM, Paul E. McKenney > wrote: >>> >>> And if nobody can be bothered to write the user-level code and test >>> this patch-series, then obviously it's

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 5:05 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Fri, Oct 13, 2017 at 1:54 PM, Paul E. McKenney > wrote: >>> >>> And if nobody can be bothered to write the user-level code and test >>> this patch-series, then obviously it's not important enough for the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 02:05:50PM -0700, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 1:54 PM, Paul E. McKenney > wrote: > >> > >> And if nobody can be bothered to write the user-level code and test > >> this patch-series, then obviously it's not important enough

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 02:05:50PM -0700, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 1:54 PM, Paul E. McKenney > wrote: > >> > >> And if nobody can be bothered to write the user-level code and test > >> this patch-series, then obviously it's not important enough for the > >> kernel to merge

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 1:54 PM, Paul E. McKenney wrote: >> >> And if nobody can be bothered to write the user-level code and test >> this patch-series, then obviously it's not important enough for the >> kernel to merge it. > > My guess is that it will take some time,

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 1:54 PM, Paul E. McKenney wrote: >> >> And if nobody can be bothered to write the user-level code and test >> this patch-series, then obviously it's not important enough for the >> kernel to merge it. > > My guess is that it will take some time, probably measured in

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 11:30:29AM -0700, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 2:35 AM, Ben Maurer wrote: > > > > I'm really excited to hear that you're open to this patch set and totally > > understand the desire for some more numbers. > > So the patch-set actually

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 11:30:29AM -0700, Linus Torvalds wrote: > On Fri, Oct 13, 2017 at 2:35 AM, Ben Maurer wrote: > > > > I'm really excited to hear that you're open to this patch set and totally > > understand the desire for some more numbers. > > So the patch-set actually looks very

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 2:35 AM, Ben Maurer wrote: > > I'm really excited to hear that you're open to this patch set and totally > understand the desire for some more numbers. So the patch-set actually looks very reasonable today. I looked through it (ok, I wasn't cc'd on the

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 2:35 AM, Ben Maurer wrote: > > I'm really excited to hear that you're open to this patch set and totally > understand the desire for some more numbers. So the patch-set actually looks very reasonable today. I looked through it (ok, I wasn't cc'd on the ppc-only patches

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 10:53 AM, Florian Weimer wrote: > On 10/13/2017 07:24 PM, Andy Lutomirski wrote: >> >> On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers >> wrote: >>> >>> - On Oct 13, 2017, at 9:56 AM, Florian Weimer

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 10:53 AM, Florian Weimer wrote: > On 10/13/2017 07:24 PM, Andy Lutomirski wrote: >> >> On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers >> wrote: >>> >>> - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com >>> wrote: >>> On 10/13/2017 03:40 PM,

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 07:24 PM, Andy Lutomirski wrote: On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers wrote: - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 07:24 PM, Andy Lutomirski wrote: On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers wrote: - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not require to store any function

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers wrote: > - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: > >> On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: >>> The proposed ABI does not require to store any function pointer. For a

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers wrote: > - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: > >> On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: >>> The proposed ABI does not require to store any function pointer. For a given >>> rseq_finish() critical

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: > On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: >> The proposed ABI does not require to store any function pointer. For a given >> rseq_finish() critical section, pointers to specific instructions (within a >>

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: > On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: >> The proposed ABI does not require to store any function pointer. For a given >> rseq_finish() critical section, pointers to specific instructions (within a >>

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not require to store any function pointer. For a given rseq_finish() critical section, pointers to specific instructions (within a function) are emitted at link-time into a struct rseq_cs: struct rseq_cs {

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not require to store any function pointer. For a given rseq_finish() critical section, pointers to specific instructions (within a function) are emitted at link-time into a struct rseq_cs: struct rseq_cs {

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 8:50 AM, Florian Weimer fwei...@redhat.com wrote: > On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: >> 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:

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 13, 2017, at 8:50 AM, Florian Weimer fwei...@redhat.com wrote: > On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: >> 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:

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: 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

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: 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

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

Hey, I'm really excited to hear that you're open to this patch set and totally understand the desire for some more numbers. I have a few thoughts and questions -- hopefully ones that could help better understand where you'd like to see more data (potentially from myself and other Facebook

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

Hey, I'm really excited to hear that you're open to this patch set and totally understand the desire for some more numbers. I have a few thoughts and questions -- hopefully ones that could help better understand where you'd like to see more data (potentially from myself and other Facebook

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

I do not hate this series, and I'd be happy to apply it, but I will repeat what I've asked for EVERY SINGLE TIME this series has come up: On Thu, Oct 12, 2017 at 4:03 PM, Mathieu Desnoyers wrote: > > Here are benchmarks of counter increment in various scenarios

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

I do not hate this series, and I'd be happy to apply it, but I will repeat what I've asked for EVERY SINGLE TIME this series has come up: On Thu, Oct 12, 2017 at 4:03 PM, Mathieu Desnoyers wrote: > > Here are benchmarks of counter increment in various scenarios compared > to restartable

[RFC PATCH v9 for 4.15 01/14] 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 v9 for 4.15 01/14] 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