From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-c6x-dev@linux-c6x.org,
uclinux-h8-devel@lists.sourceforge.jp,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org, nios2-dev@lists.rocketboards.org,
openrisc@lists.librecores.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, Linux-sh list <linux->
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-c6x-dev@linux-c6x.org,
uclinux-h8-devel@lists.sourceforge.jp,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org, nios2-dev@lists.rocketboards.org,
openrisc@lists.librecores.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.orgLinux-sh list <linux->
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-c6x-dev@linux-c6x.org,
uclinux-h8-devel@lists.sourceforge.jp,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org, nios2-dev@lists.rocketboards.org,
openrisc@lists.librecores.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
linux-xtensa@linux-xtensa.org,
linux-arch <linux-arch@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
Message-ID: <20190322193010.jGIVF3ZzZk_bCByMDJFfLWIwzuiHjfIf40JJ9e1ObSI@z> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-c6x-dev@linux-c6x.org,
uclinux-h8-devel@lists.sourceforge.jp,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
linux-mips@vger.kernel.org, nios2-dev@lists.rocketboards.org,
openrisc@lists.librecores.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.orgLinux-shlist
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 19:30:10 +0000 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
linux-mips@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org,
linux-hexagon@vger.kernel.org,
the arch/x86 maintainers <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Waiman Long <longman@redhat.com>,
uclinux-h8-devel@lists.sourceforge.jp,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
linux-um@lists.infradead.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Tim Chen <tim.c.chen@linux.intel.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
nios2-dev@lists.rocketboards.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
linux-mips@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org,
linux-hexagon@vger.kernel.org,
the arch/x86 maintainers <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Waiman Long <longman@redhat.com>,
uclinux-h8-devel@lists.sourceforge.jp,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
linux-um@lists.infradead.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Tim Chen <tim.c.chen@linux.intel.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
nios2-dev@lists.rocketboards.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-ia64@vger.kernel.org,
Linux-sh list <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
linux-mips@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-arch <linux-arch@vger.kernel.org>,
linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org,
linux-hexagon@vger.kernel.org,
the arch/x86 maintainers <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Waiman Long <longman@redhat.com>,
uclinux-h8-devel@lists.sourceforge.jp,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
linux-um@lists.infradead.org,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
openrisc@lists.librecores.org, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-alpha@vger.kernel.org"
<linux-arm-kernel@lists.infradead.org>,
linux-parisc@vger.kernel.org,
Tim Chen <tim.c.chen@linux.intel.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
nios2-dev@lists.rocketboards.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 12:30:10 -0700 [thread overview]
Message-ID: <20190322193010.azb7rmmmaclhal35@linux-r8p5> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>
On Fri, 22 Mar 2019, Linus Torvalds wrote:
>Some of them _might_ be performance-critical. There's the one on
>mmap_sem in the fault handling path, for example. And yes, I'd expect
>the normal case to very much be "no other readers or writers" for that
>one.
Yeah, the mmap_sem case in the fault path is really expecting an unlocked
state. To the point that four archs have added branch predictions, ie:
92181f190b6 (x86: optimise x86's do_page_fault (C entry point for the page fault path))
b15021d994f (powerpc/mm: Add a bunch of (un)likely annotations to do_page_fault)
And using PROFILE_ANNOTATED_BRANCHES shows pretty clearly:
(without resetting the counters)
correct incorrect % Function File Line
------- --------- - -------- ---- ----
4603685 34 0 do_user_addr_fault fault.c 1416 (bootup)
382327745 449 0 do_user_addr_fault fault.c 1416 (kernel build)
399446159 461 0 do_user_addr_fault fault.c 1416 (redis benchmark)
It would probably wouldn't harm doing the unlikely() for all archs, or
alternatively, add likely() to the atomic_long_try_cmpxchg_acquire in
patch 3 and do it implicitly but maybe that would be less flexible(?)
Thanks,
Davidlohr
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-22 19:30 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-22 14:30 [PATCH v5 0/3] locking/rwsem: Rwsem rearchitecture part 0 Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` [OpenRISC] " Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` [OpenRISC] " Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 17:01 ` Linus Torvalds
2019-03-22 17:01 ` Linus Torvalds
2019-03-22 17:01 ` Linus Torvalds
2019-03-22 17:01 ` [OpenRISC] " Linus Torvalds
2019-03-22 17:01 ` Linus Torvalds
2019-03-22 17:01 ` Linus Torvalds
2019-03-22 17:01 ` Linus Torvalds
2019-03-22 17:23 ` Waiman Long
2019-03-22 17:23 ` Waiman Long
2019-03-22 17:23 ` [OpenRISC] " Waiman Long
2019-03-22 17:23 ` Waiman Long
2019-03-22 17:23 ` Waiman Long
2019-03-22 17:23 ` Waiman Long
2019-03-22 17:23 ` Waiman Long
2019-03-22 19:30 ` Davidlohr Bueso [this message]
2019-03-22 19:30 ` Davidlohr Bueso
2019-03-22 19:30 ` Davidlohr Bueso
2019-03-22 19:30 ` [OpenRISC] " Davidlohr Bueso
2019-03-22 19:30 ` Davidlohr Bueso
2019-03-22 19:30 ` Davidlohr Bueso
2019-03-22 19:30 ` Davidlohr Bueso
2019-03-22 19:30 ` Davidlohr Bueso
2019-03-22 20:27 ` Waiman Long
2019-03-22 20:27 ` Waiman Long
2019-03-22 20:27 ` [OpenRISC] " Waiman Long
2019-03-22 20:27 ` Waiman Long
2019-03-22 20:27 ` Waiman Long
2019-03-22 20:27 ` Waiman Long
2019-03-22 20:27 ` Waiman Long
2019-04-03 10:44 ` [tip:locking/core] " tip-bot for Waiman Long
2019-04-03 12:47 ` Peter Zijlstra
2019-04-03 12:55 ` tip-bot for Waiman Long
2019-03-22 14:30 ` [PATCH v5 2/3] locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` [OpenRISC] " Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 17:07 ` Linus Torvalds
2019-03-22 17:07 ` Linus Torvalds
2019-03-22 17:07 ` [OpenRISC] " Linus Torvalds
2019-03-22 17:07 ` Linus Torvalds
2019-03-22 17:07 ` Linus Torvalds
2019-03-22 17:07 ` Linus Torvalds
2019-03-22 17:07 ` Linus Torvalds
2019-04-03 10:44 ` [tip:locking/core] " tip-bot for Waiman Long
2019-04-03 12:55 ` tip-bot for Waiman Long
2019-03-22 14:30 ` [PATCH v5 3/3] locking/rwsem: Optimize down_read_trylock() Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` [OpenRISC] " Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 14:30 ` Waiman Long
2019-03-22 17:08 ` Linus Torvalds
2019-03-22 17:08 ` Linus Torvalds
2019-03-22 17:08 ` Linus Torvalds
2019-03-22 17:08 ` [OpenRISC] " Linus Torvalds
2019-03-22 17:08 ` Linus Torvalds
2019-03-22 17:08 ` Linus Torvalds
2019-03-22 17:08 ` Linus Torvalds
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:25 ` [OpenRISC] " Russell King - ARM Linux admin
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:25 ` Russell King - ARM Linux admin
2019-03-22 17:41 ` Waiman Long
2019-03-22 17:41 ` Waiman Long
2019-03-22 17:41 ` Waiman Long
2019-03-22 17:41 ` [OpenRISC] " Waiman Long
2019-03-22 17:41 ` Waiman Long
2019-03-22 17:41 ` Waiman Long
2019-03-22 17:41 ` Waiman Long
2019-03-25 15:25 ` Christophe Leroy
2019-03-25 15:25 ` Christophe Leroy
2019-03-25 15:25 ` Christophe Leroy
2019-03-25 15:25 ` [OpenRISC] " Christophe Leroy
2019-03-25 15:25 ` Christophe Leroy
2019-03-25 15:25 ` Christophe Leroy
2019-03-25 15:25 ` Christophe Leroy
2019-04-03 10:45 ` [tip:locking/core] " tip-bot for Waiman Long
2019-04-03 12:56 ` tip-bot for Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190322193010.azb7rmmmaclhal35@linux-r8p5 \
--to=dave@stgolabs.net \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-c6x-dev@linux-c6x.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=nios2-dev@lists.rocketboards.org \
--cc=openrisc@lists.librecores.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=uclinux-h8-devel@lists.sourceforge.jp \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.