All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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@vg
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 17:23:55 +0000	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new = tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman

WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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>,
	Davidlohr Bueso <dave@stgolabs.net>,
	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 13:23:55 -0400	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new == tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman


WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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@vg
Subject: Re: [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 13:23:55 -0400	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new == tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman

WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
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, Davidlohr Bueso <dave@stgolabs.net>,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	the arch/x86 maintainers <x86@kernel.org>,
	Ingo Molnar <mingo@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 13:23:55 -0400	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new == tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman


_______________________________________________
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: Waiman Long <longman@redhat.com>
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, Davidlohr Bueso <dave@stgolabs.net>,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	the arch/x86 maintainers <x86@kernel.org>,
	Ingo Molnar <mingo@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 13:23:55 -0400	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new == tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman


WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
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, Davidlohr Bueso <dave@stgolabs.net>,
	linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org,
	the arch/x86 maintainers <x86@kernel.org>,
	Ingo Molnar <mingo@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 13:23:55 -0400	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new == tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <longman@redhat.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v5 1/3] locking/rwsem: Remove arch specific rwsem files
Date: Fri, 22 Mar 2019 13:23:55 -0400	[thread overview]
Message-ID: <15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com> (raw)
In-Reply-To: <CAHk-=wikkO-1f1=FEOEzkSnaDg3yJLP=4Vd59UCuLBztFd0KOw@mail.gmail.com>

On 03/22/2019 01:01 PM, Linus Torvalds wrote:
> On Fri, Mar 22, 2019 at 7:30 AM Waiman Long <longman@redhat.com> wrote:
>>  19 files changed, 133 insertions(+), 930 deletions(-)
> Lovely. And it all looks sane to me.
>
> So ack.
>
> The only comment I have is about __down_read_trylock(), which probably
> isn't critical enough to actually care about, but:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +       long tmp;
>> +
>> +       while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> +               if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> +                                  tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> +                       return 1;
>> +               }
>> +       }
>> +       return 0;
>> +}
> So this seems to
>
>  (a) read the line early (the whole cacheline in shared state issue)
>
>  (b) read the line again unnecessarily in the while loop
>
> Now, (a) might be explained by "well, maybe we do trylock even with
> existing readers", although I continue to think that the case we
> should optimize for is simply the uncontended one, where we don't even
> have multiple readers.
>
> But (b) just seems silly.
>
> So I wonder if it shouldn't just be
>
>         long tmp = 0;
>
>         do {
>                 long new = atomic_long_cmpxchg_acquire(&sem->count, tmp,
>                         tmp + RWSEM_ACTIVE_READ_BIAS);
>                 if (likely(new == tmp))
>                         return 1;
>                tmp = new;
>         } while (tmp >= 0);
>         return 0;
>
> which would seem simpler and solve both issues. Hmm?
>
> But honestly, I didn't check what our uses of down_read_trylock() look
> like. We have more of them than I expected, and I _think_ the normal
> case is the "nobody else holds the lock", but that's just a gut
> feeling.
>
> 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.
>
> NOTE! The above code snippet is absolutely untested, and might be
> completely wrong. Take it as a "something like this" rather than
> anything else.
>
>                    Linus

As you have noticed already, this patch is just for moving code around
without changing it. I optimize __down_read_trylock() in patch 3.

Cheers,
Longman


  reply	other threads:[~2019-03-22 17:23 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 ` 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 ` [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     ` [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:01     ` Linus Torvalds
2019-03-22 17:01     ` Linus Torvalds
2019-03-22 17:23     ` Waiman Long [this message]
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 17:23       ` Waiman Long
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 19:30       ` Davidlohr Bueso
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-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     ` [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-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     ` [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: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     ` [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:25     ` Russell King - ARM Linux admin
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-22 17:41       ` Waiman Long
2019-03-22 17:41       ` Waiman Long
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-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=15530d24-51fd-579d-2b1a-2ca98487f63f@redhat.com \
    --to=longman@redhat.com \
    --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=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=openrisc@lists.librecores.org \
    --cc=peterz@infradead.org \
    --cc=sparclinux@vg \
    --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.