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

- On Apr 7, 2016, at 4:22 PM, Andi Kleen a...@firstfloor.org wrote: >> One basic use of cpu id cache is to speed up the sched_getcpu(3) >> implementation in glibc. This is why I'm proposing it as a stand-alone > > I don't think rseq is needed for faster getcpu. I agree that rseq is not

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

- On Apr 7, 2016, at 4:22 PM, Andi Kleen a...@firstfloor.org wrote: >> One basic use of cpu id cache is to speed up the sched_getcpu(3) >> implementation in glibc. This is why I'm proposing it as a stand-alone > > I don't think rseq is needed for faster getcpu. I agree that rseq is not

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

> One basic use of cpu id cache is to speed up the sched_getcpu(3) > implementation in glibc. This is why I'm proposing it as a stand-alone I don't think rseq is needed for faster getcpu. User space has to be able handle stale return values anyways, as it has no way to lock itself to a cpu while

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

> One basic use of cpu id cache is to speed up the sched_getcpu(3) > implementation in glibc. This is why I'm proposing it as a stand-alone I don't think rseq is needed for faster getcpu. User space has to be able handle stale return values anyways, as it has no way to lock itself to a cpu while

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

- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds > wrote: >> >> Because if not, then this discussion is done for. Stop with the >> f*cking idiotic "let's look at some kernel

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

- On Apr 7, 2016, at 12:52 PM, Linus Torvalds torva...@linux-foundation.org wrote: > On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds > wrote: >> >> Because if not, then this discussion is done for. Stop with the >> f*cking idiotic "let's look at some kernel size and user-space size >> and

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

On Thu, Apr 7, 2016 at 9:50 AM, Florian Weimer wrote: > > (AFAICS set_robust_list was designed with such extensions in mind.) This is a disease among people who have been taught computer science. People think that "designing with extensions in mind" is a good idea. It's a

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

On Thu, Apr 7, 2016 at 9:50 AM, Florian Weimer wrote: > > (AFAICS set_robust_list was designed with such extensions in mind.) This is a disease among people who have been taught computer science. People think that "designing with extensions in mind" is a good idea. It's a _horrible_ idea. If

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

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds wrote: > > Because if not, then this discussion is done for. Stop with the > f*cking idiotic "let's look at some kernel size and user-space size > and try to match them up". The kernel doesn't care. The kernel MUST >

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

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds wrote: > > Because if not, then this discussion is done for. Stop with the > f*cking idiotic "let's look at some kernel size and user-space size > and try to match them up". The kernel doesn't care. The kernel MUST > NOT care. The kernel will touch

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

On 04/07/2016 06:39 PM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? We already have a similar per-thread data structure, the robust mutex list. The CPU ID is another one. So it's conceivable we might get

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

On 04/07/2016 06:39 PM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? We already have a similar per-thread data structure, the robust mutex list. The CPU ID is another one. So it's conceivable we might get

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

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? The rseq data structure, which is still being designed. OTOH, that thing could be registered

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

On Thu, Apr 7, 2016 at 9:39 AM, Linus Torvalds wrote: > Can anybody give a *coherent* and actual *real* reason why the kernel > would ever care about anything else? The rseq data structure, which is still being designed. OTOH, that thing could be registered separately by userspace. --Andy

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

On Thu, Apr 7, 2016 at 4:19 AM, Peter Zijlstra wrote: > > People objected against the fixed size scheme, but it being possible to > get a fixed TCB offset and reduce indirections is a big win IMO. Guys, I'm going to just make an executive decision here, because this whole

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

On Thu, Apr 7, 2016 at 4:19 AM, Peter Zijlstra wrote: > > People objected against the fixed size scheme, but it being possible to > get a fixed TCB offset and reduce indirections is a big win IMO. Guys, I'm going to just make an executive decision here, because this whole "fixed vs some strange

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

- On Apr 7, 2016, at 8:25 AM, Peter Zijlstra pet...@infradead.org wrote: > On Thu, Apr 07, 2016 at 02:03:53PM +0200, Florian Weimer wrote: >> > struct tlabi { >> >union { >> >__u8[64] __foo; >> >struct { >> >/* fields go here */ >> >

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

- On Apr 7, 2016, at 8:25 AM, Peter Zijlstra pet...@infradead.org wrote: > On Thu, Apr 07, 2016 at 02:03:53PM +0200, Florian Weimer wrote: >> > struct tlabi { >> >union { >> >__u8[64] __foo; >> >struct { >> >/* fields go here */ >> >

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

On 04/07/2016 02:25 PM, Peter Zijlstra wrote: > Do you have a pointer to something I can read? Because I'm clearly not > understanding the full issue here. I believe the canonical reference still is this document: For newer architectures (ppc64le,

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

On 04/07/2016 02:25 PM, Peter Zijlstra wrote: > Do you have a pointer to something I can read? Because I'm clearly not > understanding the full issue here. I believe the canonical reference still is this document: For newer architectures (ppc64le,

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

- On Apr 7, 2016, at 8:03 AM, Florian Weimer fwei...@redhat.com wrote: > On 04/07/2016 01:19 PM, Peter Zijlstra wrote: >> On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: >>> On 04/07/2016 12:31 PM, Peter Zijlstra wrote: On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian

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

- On Apr 7, 2016, at 8:03 AM, Florian Weimer fwei...@redhat.com wrote: > On 04/07/2016 01:19 PM, Peter Zijlstra wrote: >> On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: >>> On 04/07/2016 12:31 PM, Peter Zijlstra wrote: On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian

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

On Thu, Apr 07, 2016 at 02:03:53PM +0200, Florian Weimer wrote: > > struct tlabi { > > union { > > __u8[64] __foo; > > struct { > > /* fields go here */ > > }; > > }; > > } __aligned__(64); > > That's not really “fixed size” as far

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

On Thu, Apr 07, 2016 at 02:03:53PM +0200, Florian Weimer wrote: > > struct tlabi { > > union { > > __u8[64] __foo; > > struct { > > /* fields go here */ > > }; > > }; > > } __aligned__(64); > > That's not really “fixed size” as far

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

On 04/07/2016 01:19 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: >> On 04/07/2016 12:31 PM, Peter Zijlstra wrote: >>> On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: > Because ideally this structure would be part of the initial

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

On 04/07/2016 01:19 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: >> On 04/07/2016 12:31 PM, Peter Zijlstra wrote: >>> On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: > Because ideally this structure would be part of the initial

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

On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: > On 04/07/2016 12:31 PM, Peter Zijlstra wrote: > > On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: > >>> Because ideally this structure would be part of the initial (glibc) TCB > >>> with fixed offset etc. > >> > >>

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

On Thu, Apr 07, 2016 at 12:39:21PM +0200, Florian Weimer wrote: > On 04/07/2016 12:31 PM, Peter Zijlstra wrote: > > On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: > >>> Because ideally this structure would be part of the initial (glibc) TCB > >>> with fixed offset etc. > >> > >>

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

On 04/04/2016 07:01 PM, Mathieu Desnoyers wrote: > NAME >thread_local_abi - Shared memory interface between user-space >threads and the kernel We already have set_robust_list, which is conceptually similar. Florian

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

On 04/04/2016 07:01 PM, Mathieu Desnoyers wrote: > NAME >thread_local_abi - Shared memory interface between user-space >threads and the kernel We already have set_robust_list, which is conceptually similar. Florian

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

On 04/07/2016 12:31 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: >>> Because ideally this structure would be part of the initial (glibc) TCB >>> with fixed offset etc. >> >> This is not possible because we have layering violations and code >> assumes

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

On 04/07/2016 12:31 PM, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: >>> Because ideally this structure would be part of the initial (glibc) TCB >>> with fixed offset etc. >> >> This is not possible because we have layering violations and code >> assumes

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

On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: > > Because ideally this structure would be part of the initial (glibc) TCB > > with fixed offset etc. > > This is not possible because we have layering violations and code > assumes it knows the precise of the glibc TCB. I think

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

On Thu, Apr 07, 2016 at 11:01:25AM +0200, Florian Weimer wrote: > > Because ideally this structure would be part of the initial (glibc) TCB > > with fixed offset etc. > > This is not possible because we have layering violations and code > assumes it knows the precise of the glibc TCB. I think

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

On 04/05/2016 06:47 PM, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: >> On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: >> >>> Moreover, the feature set that the application knows about, glibc >>> knows about, and the kernel knows about are three

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

On 04/05/2016 06:47 PM, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: >> On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: >> >>> Moreover, the feature set that the application knows about, glibc >>> knows about, and the kernel knows about are three

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

On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: > On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > > > Moreover, the feature set that the application knows about, glibc > > knows about, and the kernel knows about are three different things. > > My intent here is to have glibc

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

On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: > On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > > > Moreover, the feature set that the application knows about, glibc > > knows about, and the kernel knows about are three different things. > > My intent here is to have glibc

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

On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > Moreover, the feature set that the application knows about, glibc > knows about, and the kernel knows about are three different things. > My intent here is to have glibc stay out of the way as much as possible, > since this is really an interface

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

On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > Moreover, the feature set that the application knows about, glibc > knows about, and the kernel knows about are three different things. > My intent here is to have glibc stay out of the way as much as possible, > since this is really an interface

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

- On Apr 4, 2016, at 3:46 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 4, 2016, at 1:11 PM, H. Peter Anvin h...@zytor.com wrote: > >> On 04/04/16 10:01, Mathieu Desnoyers wrote: >>> >>> Changes since v5: >>> - Rename "getcpu_cache" to "thread_local_abi",

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

- On Apr 4, 2016, at 3:46 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Apr 4, 2016, at 1:11 PM, H. Peter Anvin h...@zytor.com wrote: > >> On 04/04/16 10:01, Mathieu Desnoyers wrote: >>> >>> Changes since v5: >>> - Rename "getcpu_cache" to "thread_local_abi",

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

- On Apr 4, 2016, at 1:11 PM, H. Peter Anvin h...@zytor.com wrote: > On 04/04/16 10:01, Mathieu Desnoyers wrote: >> >> Changes since v5: >> - Rename "getcpu_cache" to "thread_local_abi", allowing to extend >> this system call to cover future features such as restartable critical >>

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

- On Apr 4, 2016, at 1:11 PM, H. Peter Anvin h...@zytor.com wrote: > On 04/04/16 10:01, Mathieu Desnoyers wrote: >> >> Changes since v5: >> - Rename "getcpu_cache" to "thread_local_abi", allowing to extend >> this system call to cover future features such as restartable critical >>

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

On 04/04/16 10:01, Mathieu Desnoyers wrote: > > Changes since v5: > - Rename "getcpu_cache" to "thread_local_abi", allowing to extend > this system call to cover future features such as restartable critical > sections. Generalizing this system call ensures that we can add > features similar

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

On 04/04/16 10:01, Mathieu Desnoyers wrote: > > Changes since v5: > - Rename "getcpu_cache" to "thread_local_abi", allowing to extend > this system call to cover future features such as restartable critical > sections. Generalizing this system call ensures that we can add > features similar

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

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

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

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