There are some interesting things one could do with a similar system at
the kernel level.
If we had a table of IP ranges in the kernel that specify critical
sections with the restart points defined then the kernel could consult
that when preempting kernel threads and set the IP to the
restart poin
On Tue, May 26, 2015 at 2:18 PM, Andy Lutomirski wrote:
> On Tue, May 26, 2015 at 2:04 PM, Mathieu Desnoyers
>>
>>>
>>> It's too bad that not all architectures have a single-instruction
>>> unlocked compare-and-exchange.
>>
>> Based on my benchmarks, it's not clear that single-instruction
>> unloc
On Tue, May 26, 2015 at 2:20 PM, Andi Kleen wrote:
>
> I haven't thought too much about it, but doing it in a vdso seems
> reasonable. It would mean that the scheduler hot path would
> need to know about its address though.
>
>> > You appear to summarize the two things that are added to the kernel
I haven't thought too much about it, but doing it in a vdso seems
reasonable. It would mean that the scheduler hot path would
need to know about its address though.
> > You appear to summarize the two things that are added to the kernel with
> > this RFC patch:
> > - faster getcpu(): 12.7 ns -> 0
On Tue, May 26, 2015 at 2:04 PM, Mathieu Desnoyers
wrote:
> - Original Message -
>> On May 25, 2015 11:54 AM, "Andy Lutomirski" wrote:
> [...]
>> I might be guilty of being too x86-centric here. On x86, as long as
>> the lock and unlock primitives are sufficiently atomic, everything
>> s
- Original Message -
> On May 25, 2015 11:54 AM, "Andy Lutomirski" wrote:
[...]
> I might be guilty of being too x86-centric here. On x86, as long as
> the lock and unlock primitives are sufficiently atomic, everything
> should be okay. On other architectures, though, a primitive that
>
On Tue, May 26, 2015 at 1:38 PM, Mathieu Desnoyers
wrote:
> - Original Message -
>> [cc: hpa, Borislav and Andi]
>>
>> On Mon, May 25, 2015 at 11:30 AM, Mathieu Desnoyers
>> wrote:
>> > - Original Message -
>> >> On May 23, 2015 10:09 AM, "Mathieu Desnoyers"
>> >> wrote:
>> >> >
- Original Message -
> [cc: hpa, Borislav and Andi]
>
> On Mon, May 25, 2015 at 11:30 AM, Mathieu Desnoyers
> wrote:
> > - Original Message -
> >> On May 23, 2015 10:09 AM, "Mathieu Desnoyers"
> >> wrote:
> >> >
> >> > - Original Message -
> >> > > On Fri, May 22, 2015 at
On May 25, 2015 11:54 AM, "Andy Lutomirski" wrote:
>
> [cc: hpa, Borislav and Andi]
>
> On Mon, May 25, 2015 at 11:30 AM, Mathieu Desnoyers
> wrote:
> > - Original Message -
> >> On May 23, 2015 10:09 AM, "Mathieu Desnoyers"
> >> wrote:
> >> >
> >> > - Original Message -
> >> > >
- Original Message -
> On Thu, May 21, 2015 at 7:44 AM, Mathieu Desnoyers
> wrote:
> > Expose a new system call allowing userspace threads to register
> > a TLS area used as an ABI between the kernel and userspace to
> > share information required to create efficient per-cpu critical
> >
[cc: hpa, Borislav and Andi]
On Mon, May 25, 2015 at 11:30 AM, Mathieu Desnoyers
wrote:
> - Original Message -
>> On May 23, 2015 10:09 AM, "Mathieu Desnoyers"
>> wrote:
>> >
>> > - Original Message -
>> > > On Fri, May 22, 2015 at 2:34 PM, Mathieu Desnoyers
>> > > wrote:
>> > >
- Original Message -
> On May 23, 2015 10:09 AM, "Mathieu Desnoyers"
> wrote:
> >
> > - Original Message -
> > > On Fri, May 22, 2015 at 2:34 PM, Mathieu Desnoyers
> > > wrote:
> > > > - Original Message -
> > > >> On Fri, May 22, 2015 at 1:26 PM, Michael Kerrisk
> > > >>
On Thu, May 21, 2015 at 7:44 AM, Mathieu Desnoyers
wrote:
> Expose a new system call allowing userspace threads to register
> a TLS area used as an ABI between the kernel and userspace to
> share information required to create efficient per-cpu critical
> sections in user-space.
Not a way in hell
On May 23, 2015 10:09 AM, "Mathieu Desnoyers"
wrote:
>
> - Original Message -
> > On Fri, May 22, 2015 at 2:34 PM, Mathieu Desnoyers
> > wrote:
> > > - Original Message -
> > >> On Fri, May 22, 2015 at 1:26 PM, Michael Kerrisk
> > >> wrote:
> > >> > [CC += linux-api@]
> > >> >
>
- Original Message -
> On Fri, May 22, 2015 at 2:34 PM, Mathieu Desnoyers
> wrote:
> > - Original Message -
> >> On Fri, May 22, 2015 at 1:26 PM, Michael Kerrisk
> >> wrote:
> >> > [CC += linux-api@]
> >> >
> >> > On Thu, May 21, 2015 at 4:44 PM, Mathieu Desnoyers
> >> > wrote:
>
On Fri, May 22, 2015 at 2:34 PM, Mathieu Desnoyers
wrote:
> - Original Message -
>> On Fri, May 22, 2015 at 1:26 PM, Michael Kerrisk
>> wrote:
>> > [CC += linux-api@]
>> >
>> > On Thu, May 21, 2015 at 4:44 PM, Mathieu Desnoyers
>> > wrote:
>> >> Expose a new system call allowing userspac
On Fri, May 22, 2015 at 1:53 PM, Andy Lutomirski wrote:
> Create an array of user-managed locks, one per cpu. Call them lock[i]
> for 0 <= i < ncpus.
>
> To acquire, look up your CPU number. Then, atomically, check that
> lock[cpu] isn't held and, if so, mark it held and record both your tid
> a
- Original Message -
> On Fri, May 22, 2015 at 1:26 PM, Michael Kerrisk
> wrote:
> > [CC += linux-api@]
> >
> > On Thu, May 21, 2015 at 4:44 PM, Mathieu Desnoyers
> > wrote:
> >> Expose a new system call allowing userspace threads to register
> >> a TLS area used as an ABI between the ker
On Fri, May 22, 2015 at 1:26 PM, Michael Kerrisk wrote:
> [CC += linux-api@]
>
> On Thu, May 21, 2015 at 4:44 PM, Mathieu Desnoyers
> wrote:
>> Expose a new system call allowing userspace threads to register
>> a TLS area used as an ABI between the kernel and userspace to
>> share information req
[CC += linux-api@]
On Thu, May 21, 2015 at 4:44 PM, Mathieu Desnoyers
wrote:
> Expose a new system call allowing userspace threads to register
> a TLS area used as an ABI between the kernel and userspace to
> share information required to create efficient per-cpu critical
> sections in user-space
- Original Message -
> Very nice!
>
> Some inline notes:
>
> On Thu, May 21, 2015 at 7:44 AM, Mathieu Desnoyers
> wrote:
> > Expose a new system call allowing userspace threads to register
> > a TLS area used as an ABI between the kernel and userspace to
> > share information required to
Very nice!
Some inline notes:
On Thu, May 21, 2015 at 7:44 AM, Mathieu Desnoyers
wrote:
> Expose a new system call allowing userspace threads to register
> a TLS area used as an ABI between the kernel and userspace to
> share information required to create efficient per-cpu critical
> sections i
On Thu, May 21, 2015 at 12:08 PM, Mathieu Desnoyers
wrote:
> - Original Message -
>> On Thu, May 21, 2015 at 10:44:47AM -0400, Mathieu Desnoyers wrote:
>>
>> > +struct thread_percpu_user {
>> > + int32_t nesting;
>> > + int32_t signal_sent;
>> > + int32_t signo;
>> > + int32_t curr
- Original Message -
> On Thu, May 21, 2015 at 10:44:47AM -0400, Mathieu Desnoyers wrote:
>
> > +struct thread_percpu_user {
> > + int32_t nesting;
> > + int32_t signal_sent;
> > + int32_t signo;
> > + int32_t current_cpu;
> > +};
>
> I would require this thing be naturally aligne
- Original Message -
> On Thu, May 21, 2015 at 10:44:47AM -0400, Mathieu Desnoyers wrote:
> > Expose a new system call allowing userspace threads to register
> > a TLS area used as an ABI between the kernel and userspace to
> > share information required to create efficient per-cpu critical
On Thu, May 21, 2015 at 10:44:47AM -0400, Mathieu Desnoyers wrote:
> +struct thread_percpu_user {
> + int32_t nesting;
> + int32_t signal_sent;
> + int32_t signo;
> + int32_t current_cpu;
> +};
I would require this thing be naturally aligned, such that it does not
cross cacheline
On Thu, May 21, 2015 at 10:44:47AM -0400, Mathieu Desnoyers wrote:
> Expose a new system call allowing userspace threads to register
> a TLS area used as an ABI between the kernel and userspace to
> share information required to create efficient per-cpu critical
> sections in user-space.
>
> This
27 matches
Mail list logo
