All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.