From: Mike Galbraith <efault@gmx.de>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Rik van Riel <riel@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Davidlohr Bueso <davidlohr.bueso@hp.com>,
hhuang@redhat.com, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 2/4] ipc/sem: seperate wait-for-zero and alter tasks into seperate queues
Date: Sat, 01 Jun 2013 12:03:19 +0200 [thread overview]
Message-ID: <1370080999.7268.5.camel@marge.simpson.net> (raw)
In-Reply-To: <51A9BCDA.9040006@colorfullife.com>
On Sat, 2013-06-01 at 11:20 +0200, Manfred Spraul wrote:
> Hi Rik,
>
> On 05/27/2013 07:57 PM, Rik van Riel wrote:
> > On 05/26/2013 05:08 AM, Manfred Spraul wrote:
> >> Introduce seperate queues for operations that do not modify the
> >> semaphore values.
> >> Advantages:
> >> - Simpler logic in check_restart().
> >> - Faster update_queue(): Right now, all wait-for-zero operations
> >> are always tested, even if the semaphore value is not 0.
> >> - wait-for-zero gets again priority, as in linux <=3.0.9
> >
> > Whether this complexity is wanted is not for
> > me to decide, as I am not the ipc/sem.c
> > maintainer. I'll leave that up to Andrew and Linus.
> >
> We can have only one: Either more logic or unoptimized loops.
> But I don't think that the complexity increases that much, e.g. some
> parts (e.g. check_restart()) get much simpler.
>
> But:
> Mike Galbraith ran 3.10-rc3 with and without my changes on a 4-socket
> 64-core system, and for me the results appears to be quite slow:
> - semop-multi 256 64: around 600.000 ops/sec, both with and without my
> additional patches [difference around 1%]
> That is slower than my 1.4 GHz i3 with 3.9 - I get around 1.000.000
> ops/sec
> Is that expected?
> My only idea would be trashing from writing sma->sem_otime.
>
> - osim [i.e.: with reschedules] is much slower: around 21 us per schedule.
> Perhaps the scheduler didn't pair the threads optimally: intra-cpu
> reschedules
> take around 2 us on my i3, inter-cpu reschedules around 16 us.
I got -rt backports working, and it's faster at semop-multi, but one
hell of a lot slower at osim. The goto again loop in sem_lock() is a
livelock in -rt, I had to do that differently.
-rtm is with our patches added, -rt is backport without.
vogelweide:/abuild/mike/:[0]# uname -r
3.8.13-rt9-rtm
vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64
cpus 64, threads: 256, semaphores: 64, test duration: 30 secs
total operations: 33553800, ops/sec 1118460
vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64
cpus 64, threads: 256, semaphores: 64, test duration: 30 secs
total operations: 33344598, ops/sec 1111486
vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64
cpus 64, threads: 256, semaphores: 64, test duration: 30 secs
total operations: 33655348, ops/sec 1121844
vogelweide:/abuild/mike/:[0]#
vogelweide:/abuild/mike/:[130]# ./osim 64 256 1000000 0 0
osim <sems> <tasks> <loops> <busy-in> <busy-out>
osim: using a semaphore array with 64 semaphores.
osim: using 256 tasks.
osim: each thread loops 3907 times
osim: each thread busyloops 0 loops outside and 0 loops inside.
total execution time: 12.296215 seconds for 1000192 loops
per loop execution time: 12.293 usec
vogelweide:/abuild/mike/:[0]# ./osim 64 256 1000000 0 0
osim <sems> <tasks> <loops> <busy-in> <busy-out>
osim: using a semaphore array with 64 semaphores.
osim: using 256 tasks.
osim: each thread loops 3907 times
osim: each thread busyloops 0 loops outside and 0 loops inside.
total execution time: 11.613663 seconds for 1000192 loops
per loop execution time: 11.611 usec
vogelweide:/abuild/mike/:[0]# ./osim 64 256 1000000 0 0
osim <sems> <tasks> <loops> <busy-in> <busy-out>
osim: using a semaphore array with 64 semaphores.
osim: using 256 tasks.
osim: each thread loops 3907 times
osim: each thread busyloops 0 loops outside and 0 loops inside.
total execution time: 13.755537 seconds for 1000192 loops
per loop execution time: 13.752 usec
vogelweide:/abuild/mike/:[0]# uname -r
3.8.13-rt9-rt
vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64
cpus 64, threads: 256, semaphores: 64, test duration: 30 secs
total operations: 37343656, ops/sec 1244788
vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64
cpus 64, threads: 256, semaphores: 64, test duration: 30 secs
total operations: 37226496, ops/sec 1240883
vogelweide:/abuild/mike/:[0]# ./semop-multi 256 64
cpus 64, threads: 256, semaphores: 64, test duration: 30 secs
total operations: 36730816, ops/sec 1224360
vogelweide:/abuild/mike/:[0]#
vogelweide:/abuild/mike/:[0]# ./osim 64 256 1000000 0 0
osim <sems> <tasks> <loops> <busy-in> <busy-out>
osim: using a semaphore array with 64 semaphores.
osim: using 256 tasks.
osim: each thread loops 3907 times
osim: each thread busyloops 0 loops outside and 0 loops inside.
total execution time: 12.676632 seconds for 1000192 loops
per loop execution time: 12.674 usec
vogelweide:/abuild/mike/:[0]# ./osim 64 256 1000000 0 0
osim <sems> <tasks> <loops> <busy-in> <busy-out>
osim: using a semaphore array with 64 semaphores.
osim: using 256 tasks.
osim: each thread loops 3907 times
osim: each thread busyloops 0 loops outside and 0 loops inside.
total execution time: 14.166756 seconds for 1000192 loops
per loop execution time: 14.164 usec
vogelweide:/abuild/mike/:[0]# ./osim 64 256 1000000 0 0
osim <sems> <tasks> <loops> <busy-in> <busy-out>
osim: using a semaphore array with 64 semaphores.
osim: using 256 tasks.
osim: each thread loops 3907 times
osim: each thread busyloops 0 loops outside and 0 loops inside.
total execution time: 15.116200 seconds for 1000192 loops
per loop execution time: 15.113 use
next prev parent reply other threads:[~2013-06-01 10:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-26 9:08 [PATCH 0/4] ipc/sem.c: Bug fixes, regression fixes, v3 Manfred Spraul
2013-05-26 9:08 ` [PATCH 1/4] ipc/sem.c: Fix missing wakeups in do_smart_update_queue() Manfred Spraul
2013-05-27 17:51 ` Rik van Riel
2013-05-27 19:53 ` Manfred Spraul
2013-05-26 9:08 ` [PATCH 2/4] ipc/sem: seperate wait-for-zero and alter tasks into seperate queues Manfred Spraul
2013-05-27 17:57 ` Rik van Riel
2013-06-01 9:20 ` Manfred Spraul
2013-06-01 10:03 ` Mike Galbraith [this message]
2013-06-01 10:05 ` Mike Galbraith
2013-06-01 11:04 ` Mike Galbraith
2013-06-01 11:52 ` Manfred Spraul
2013-05-26 9:08 ` [PATCH 3/4] ipc/sem.c: Always use only one queue for alter operations Manfred Spraul
2013-05-27 18:00 ` Rik van Riel
2013-05-26 9:08 ` [PATCH 4/4] ipc/sem.c: Rename try_atomic_semop() to perform_atomic_semop(), docu update Manfred Spraul
2013-05-27 17:59 ` Rik van Riel
2013-05-26 17:37 ` [PATCH 0/4] ipc/sem.c: Bug fixes, regression fixes, v3 Linus Torvalds
2013-05-26 20:50 ` Davidlohr Bueso
2013-05-26 22:59 ` Linus Torvalds
2013-05-27 15:57 ` Manfred Spraul
2013-05-28 20:37 ` Davidlohr Bueso
2013-05-27 2:04 ` Greg KH
2013-05-27 17:50 ` Rik van Riel
2013-05-27 19:57 ` Greg KH
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=1370080999.7268.5.camel@marge.simpson.net \
--to=efault@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=davidlohr.bueso@hp.com \
--cc=hhuang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®