From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
linux-arch@vger.kernel.org, x86@kernel.org,
Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
Date: Mon, 11 Feb 2019 08:11:59 +0100 [thread overview]
Message-ID: <20190211071159.GA55579@gmail.com> (raw)
In-Reply-To: <a610aeb2-b1cb-0d57-8078-97d1051481f9@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> > atomic functions are properly implemented. So we can remove those arch
> > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance
> > effort.
> >
> > Currently, only x86, alpha and ia64 have implemented architecture
> > specific fast paths. I don't have access to alpha and ia64 systems for
> > testing, but they are legacy systems that are not likely to be updated
> > to the latest kernel anyway.
> >
> > By using a rwsem microbenchmark, the total locking rates on a 4-socket
> > 56-core 112-thread x86-64 system before and after the patch were as
> > follows (mixed means equal # of read and write locks):
> >
> > Before Patch After Patch
> > # of Threads wlock rlock mixed wlock rlock mixed
> > ------------ ----- ----- ----- ----- ----- -----
> > 1 27,373 29,409 28,170 28,773 30,164 29,276
> > 2 7,697 14,922 1,703 7,435 15,167 1,729
> > 4 6,987 14,285 1,490 7,181 14,438 1,330
> > 8 6,650 13,652 761 6,918 13,796 718
> > 16 6,434 15,729 713 6,554 16,030 625
> > 32 5,590 15,312 552 6,124 15,344 471
> > 64 5,980 15,478 61 5,668 15,509 58
> >
> > There were some run-to-run variations for the multi-thread tests. For
> > x86-64, using the generic C code fast path seems to be a liitle bit
> > faster than the assembly version especially for read-lock and when lock
> > contention is low. Looking at the assembly version of the fast paths,
> > there are assembly to/from C code wrappers that save and restore all
> > the callee-clobbered registers (7 registers on x86-64). The assembly
> > generated from the generic C code doesn't need to do that. That may
> > explain the slight performance gain here.
> >
> > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h
> > as no other code other than those under kernel/locking needs to access
> > the internal rwsem macros and functions.
> >
> > Signed-off-by: Waiman Long <longman@redhat.com>
>
> I have decided to break the rwsem patchset that I sent out on last
> Thursday into 3 parts. This patch is part 0 as it touches a number of
> arch specific files and so have the widest distribution. I would like to
> get it merged first. Part 1 will be patches 1-10 (except 4) of my
> original rwsem patchset. This part moves things around, adds more
> debugging capability and lays the ground work for the next part. Part 2
> will contains the remaining patches which are the real beef of the whole
> patchset.
Sounds good to me - I've merged this patch, will push it out after
testing.
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
linux-arch@vger.kernel.org, x86@kernel.org,
Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
Date: Mon, 11 Feb 2019 07:11:59 +0000 [thread overview]
Message-ID: <20190211071159.GA55579@gmail.com> (raw)
In-Reply-To: <a610aeb2-b1cb-0d57-8078-97d1051481f9@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> > atomic functions are properly implemented. So we can remove those arch
> > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance
> > effort.
> >
> > Currently, only x86, alpha and ia64 have implemented architecture
> > specific fast paths. I don't have access to alpha and ia64 systems for
> > testing, but they are legacy systems that are not likely to be updated
> > to the latest kernel anyway.
> >
> > By using a rwsem microbenchmark, the total locking rates on a 4-socket
> > 56-core 112-thread x86-64 system before and after the patch were as
> > follows (mixed means equal # of read and write locks):
> >
> > Before Patch After Patch
> > # of Threads wlock rlock mixed wlock rlock mixed
> > ------------ ----- ----- ----- ----- ----- -----
> > 1 27,373 29,409 28,170 28,773 30,164 29,276
> > 2 7,697 14,922 1,703 7,435 15,167 1,729
> > 4 6,987 14,285 1,490 7,181 14,438 1,330
> > 8 6,650 13,652 761 6,918 13,796 718
> > 16 6,434 15,729 713 6,554 16,030 625
> > 32 5,590 15,312 552 6,124 15,344 471
> > 64 5,980 15,478 61 5,668 15,509 58
> >
> > There were some run-to-run variations for the multi-thread tests. For
> > x86-64, using the generic C code fast path seems to be a liitle bit
> > faster than the assembly version especially for read-lock and when lock
> > contention is low. Looking at the assembly version of the fast paths,
> > there are assembly to/from C code wrappers that save and restore all
> > the callee-clobbered registers (7 registers on x86-64). The assembly
> > generated from the generic C code doesn't need to do that. That may
> > explain the slight performance gain here.
> >
> > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h
> > as no other code other than those under kernel/locking needs to access
> > the internal rwsem macros and functions.
> >
> > Signed-off-by: Waiman Long <longman@redhat.com>
>
> I have decided to break the rwsem patchset that I sent out on last
> Thursday into 3 parts. This patch is part 0 as it touches a number of
> arch specific files and so have the widest distribution. I would like to
> get it merged first. Part 1 will be patches 1-10 (except 4) of my
> original rwsem patchset. This part moves things around, adds more
> debugging capability and lays the ground work for the next part. Part 2
> will contains the remaining patches which are the real beef of the whole
> patchset.
Sounds good to me - I've merged this patch, will push it out after
testing.
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, linux-arch@vger.kernel.org,
Davidlohr Bueso <dave@stgolabs.net>,
linux-hexagon@vger.kernel.org, x86@kernel.org,
Ingo Molnar <mingo@redhat.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
linuxppc-dev@lists.ozlabs.org, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
Date: Mon, 11 Feb 2019 08:11:59 +0100 [thread overview]
Message-ID: <20190211071159.GA55579@gmail.com> (raw)
In-Reply-To: <a610aeb2-b1cb-0d57-8078-97d1051481f9@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> > atomic functions are properly implemented. So we can remove those arch
> > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance
> > effort.
> >
> > Currently, only x86, alpha and ia64 have implemented architecture
> > specific fast paths. I don't have access to alpha and ia64 systems for
> > testing, but they are legacy systems that are not likely to be updated
> > to the latest kernel anyway.
> >
> > By using a rwsem microbenchmark, the total locking rates on a 4-socket
> > 56-core 112-thread x86-64 system before and after the patch were as
> > follows (mixed means equal # of read and write locks):
> >
> > Before Patch After Patch
> > # of Threads wlock rlock mixed wlock rlock mixed
> > ------------ ----- ----- ----- ----- ----- -----
> > 1 27,373 29,409 28,170 28,773 30,164 29,276
> > 2 7,697 14,922 1,703 7,435 15,167 1,729
> > 4 6,987 14,285 1,490 7,181 14,438 1,330
> > 8 6,650 13,652 761 6,918 13,796 718
> > 16 6,434 15,729 713 6,554 16,030 625
> > 32 5,590 15,312 552 6,124 15,344 471
> > 64 5,980 15,478 61 5,668 15,509 58
> >
> > There were some run-to-run variations for the multi-thread tests. For
> > x86-64, using the generic C code fast path seems to be a liitle bit
> > faster than the assembly version especially for read-lock and when lock
> > contention is low. Looking at the assembly version of the fast paths,
> > there are assembly to/from C code wrappers that save and restore all
> > the callee-clobbered registers (7 registers on x86-64). The assembly
> > generated from the generic C code doesn't need to do that. That may
> > explain the slight performance gain here.
> >
> > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h
> > as no other code other than those under kernel/locking needs to access
> > the internal rwsem macros and functions.
> >
> > Signed-off-by: Waiman Long <longman@redhat.com>
>
> I have decided to break the rwsem patchset that I sent out on last
> Thursday into 3 parts. This patch is part 0 as it touches a number of
> arch specific files and so have the widest distribution. I would like to
> get it merged first. Part 1 will be patches 1-10 (except 4) of my
> original rwsem patchset. This part moves things around, adds more
> debugging capability and lays the ground work for the next part. Part 2
> will contains the remaining patches which are the real beef of the whole
> patchset.
Sounds good to me - I've merged this patch, will push it out after
testing.
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, linux-arch@vger.kernel.org,
Davidlohr Bueso <dave@stgolabs.net>,
linux-hexagon@vger.kernel.org, x86@kernel.org,
Ingo Molnar <mingo@redhat.com>,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
linuxppc-dev@lists.ozlabs.org, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
Date: Mon, 11 Feb 2019 08:11:59 +0100 [thread overview]
Message-ID: <20190211071159.GA55579@gmail.com> (raw)
In-Reply-To: <a610aeb2-b1cb-0d57-8078-97d1051481f9@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> > atomic functions are properly implemented. So we can remove those arch
> > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance
> > effort.
> >
> > Currently, only x86, alpha and ia64 have implemented architecture
> > specific fast paths. I don't have access to alpha and ia64 systems for
> > testing, but they are legacy systems that are not likely to be updated
> > to the latest kernel anyway.
> >
> > By using a rwsem microbenchmark, the total locking rates on a 4-socket
> > 56-core 112-thread x86-64 system before and after the patch were as
> > follows (mixed means equal # of read and write locks):
> >
> > Before Patch After Patch
> > # of Threads wlock rlock mixed wlock rlock mixed
> > ------------ ----- ----- ----- ----- ----- -----
> > 1 27,373 29,409 28,170 28,773 30,164 29,276
> > 2 7,697 14,922 1,703 7,435 15,167 1,729
> > 4 6,987 14,285 1,490 7,181 14,438 1,330
> > 8 6,650 13,652 761 6,918 13,796 718
> > 16 6,434 15,729 713 6,554 16,030 625
> > 32 5,590 15,312 552 6,124 15,344 471
> > 64 5,980 15,478 61 5,668 15,509 58
> >
> > There were some run-to-run variations for the multi-thread tests. For
> > x86-64, using the generic C code fast path seems to be a liitle bit
> > faster than the assembly version especially for read-lock and when lock
> > contention is low. Looking at the assembly version of the fast paths,
> > there are assembly to/from C code wrappers that save and restore all
> > the callee-clobbered registers (7 registers on x86-64). The assembly
> > generated from the generic C code doesn't need to do that. That may
> > explain the slight performance gain here.
> >
> > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h
> > as no other code other than those under kernel/locking needs to access
> > the internal rwsem macros and functions.
> >
> > Signed-off-by: Waiman Long <longman@redhat.com>
>
> I have decided to break the rwsem patchset that I sent out on last
> Thursday into 3 parts. This patch is part 0 as it touches a number of
> arch specific files and so have the widest distribution. I would like to
> get it merged first. Part 1 will be patches 1-10 (except 4) of my
> original rwsem patchset. This part moves things around, adds more
> debugging capability and lays the ground work for the next part. Part 2
> will contains the remaining patches which are the real beef of the whole
> patchset.
Sounds good to me - I've merged this patch, will push it out after
testing.
Thanks,
Ingo
_______________________________________________
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-02-11 7:11 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 2:00 [PATCH] locking/rwsem: Remove arch specific rwsem files Waiman Long
2019-02-11 2:00 ` Waiman Long
2019-02-11 2:00 ` Waiman Long
2019-02-11 2:00 ` Waiman Long
2019-02-11 2:08 ` Waiman Long
2019-02-11 2:08 ` Waiman Long
2019-02-11 2:08 ` Waiman Long
2019-02-11 2:08 ` Waiman Long
2019-02-11 7:11 ` Ingo Molnar [this message]
2019-02-11 7:11 ` Ingo Molnar
2019-02-11 7:11 ` Ingo Molnar
2019-02-11 7:11 ` Ingo Molnar
2019-02-11 10:39 ` Ingo Molnar
2019-02-11 10:39 ` Ingo Molnar
2019-02-11 10:39 ` Ingo Molnar
2019-02-11 10:39 ` Ingo Molnar
2019-02-11 10:52 ` Will Deacon
2019-02-11 10:52 ` Will Deacon
2019-02-11 10:52 ` Will Deacon
2019-02-11 10:55 ` Ingo Molnar
2019-02-11 10:55 ` Ingo Molnar
2019-02-11 10:55 ` Ingo Molnar
2019-02-11 10:55 ` Ingo Molnar
2019-02-11 13:32 ` Waiman Long
2019-02-11 13:32 ` Waiman Long
2019-02-11 13:32 ` Waiman Long
2019-02-11 13:32 ` Waiman Long
2019-02-11 9:36 ` Peter Zijlstra
2019-02-11 9:36 ` Peter Zijlstra
2019-02-11 9:36 ` Peter Zijlstra
2019-02-11 9:36 ` Peter Zijlstra
2019-02-11 9:40 ` Peter Zijlstra
2019-02-11 9:40 ` Peter Zijlstra
2019-02-11 9:40 ` Peter Zijlstra
2019-02-11 9:40 ` Peter Zijlstra
2019-02-11 10:57 ` Peter Zijlstra
2019-02-11 10:57 ` Peter Zijlstra
2019-02-11 10:57 ` Peter Zijlstra
2019-02-11 10:57 ` Peter Zijlstra
2019-02-11 11:58 ` Peter Zijlstra
2019-02-11 11:58 ` Peter Zijlstra
2019-02-11 11:58 ` Peter Zijlstra
2019-02-11 11:58 ` Peter Zijlstra
2019-02-11 16:35 ` Waiman Long
2019-02-11 16:35 ` Waiman Long
2019-02-11 16:35 ` Waiman Long
2019-02-11 16:35 ` Waiman Long
2019-02-11 17:04 ` Peter Zijlstra
2019-02-11 17:04 ` Peter Zijlstra
2019-02-11 17:04 ` Peter Zijlstra
2019-02-11 17:04 ` Peter Zijlstra
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=20190211071159.GA55579@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave@stgolabs.net \
--cc=hpa@zytor.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/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.