From: Manfred Spraul <manfred@colorfullife.com>
To: Davidlohr Bueso <dave@stgolabs.net>, akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 2/5] ipc/sem: rework task wakeups
Date: Mon, 19 Sep 2016 20:26:31 +0200 [thread overview]
Message-ID: <67e32fa9-4a51-6d05-88bf-3c38cb1a8d3e@colorfullife.com> (raw)
In-Reply-To: <1474225896-10066-3-git-send-email-dave@stgolabs.net>
On 09/18/2016 09:11 PM, Davidlohr Bueso wrote:
> Our sysv sems have been using the notion of lockless wakeups for a while,
> ever since 0a2b9d4c796 (ipc/sem.c: move wake_up_process out of the spinlock
> section), in order to reduce the sem_lock hold times. This in-house pending
> queue can be replaced by wake_q (just like all the rest of ipc now), in that
> it provides the following advantages:
>
> o Simplifies and gets rid of unnecessary code.
>
> o We get rid of the IN_WAKEUP complexities. Given that wake_q_add() grabs
> reference to the task, if awoken due to an unrelated event, between the
> wake_q_add() and wake_up_q() window, we cannot race with sys_exit and the
> imminent call to wake_up_process().
>
> o By not spinning IN_WAKEUP, we no longer need to disable preemption.
>
> In consequence, the wakeup paths (after schedule(), that is) must acknowledge
> an external signal/event, as well spurious wakeup occurring during the pending
> wakeup window. Obviously no changes in semantics that could be visible to the
> user. The fastpath is _only_ for when we know for sure that we were awoken due
> to a the waker's successful semop call (queue.status is not -EINTR).
>
> On a 48-core Haswell, running the ipcscale 'waitforzero' test, the following
> is seen with increasing thread counts:
>
> v4.8-rc5 v4.8-rc5
> semopv2
> Hmean sembench-sem-2 574733.00 ( 0.00%) 578322.00 ( 0.62%)
> Hmean sembench-sem-8 811708.00 ( 0.00%) 824689.00 ( 1.59%)
> Hmean sembench-sem-12 842448.00 ( 0.00%) 845409.00 ( 0.35%)
> Hmean sembench-sem-21 933003.00 ( 0.00%) 977748.00 ( 4.80%)
> Hmean sembench-sem-48 935910.00 ( 0.00%) 1004759.00 ( 7.36%)
> Hmean sembench-sem-79 937186.00 ( 0.00%) 983976.00 ( 4.99%)
> Hmean sembench-sem-234 974256.00 ( 0.00%) 1060294.00 ( 8.83%)
> Hmean sembench-sem-265 975468.00 ( 0.00%) 1016243.00 ( 4.18%)
> Hmean sembench-sem-296 991280.00 ( 0.00%) 1042659.00 ( 5.18%)
> Hmean sembench-sem-327 975415.00 ( 0.00%) 1029977.00 ( 5.59%)
> Hmean sembench-sem-358 1014286.00 ( 0.00%) 1049624.00 ( 3.48%)
> Hmean sembench-sem-389 972939.00 ( 0.00%) 1043127.00 ( 7.21%)
> Hmean sembench-sem-420 981909.00 ( 0.00%) 1056747.00 ( 7.62%)
> Hmean sembench-sem-451 990139.00 ( 0.00%) 1051609.00 ( 6.21%)
> Hmean sembench-sem-482 965735.00 ( 0.00%) 1040313.00 ( 7.72%)
>
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Acked-by: Manfred Spraul <manfred@colorfullife.com>
--
Manfred
next prev parent reply other threads:[~2016-09-19 18:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-18 19:11 [PATCH -next v2 0/5] ipc/sem: semop(2) improvements Davidlohr Bueso
2016-09-18 19:11 ` [PATCH 1/5] ipc/sem: do not call wake_sem_queue_do() prematurely Davidlohr Bueso
2016-09-18 19:11 ` [PATCH 2/5] ipc/sem: rework task wakeups Davidlohr Bueso
2016-09-19 18:26 ` Manfred Spraul [this message]
2016-09-18 19:11 ` [PATCH 3/5] ipc/sem: optimize perform_atomic_semop() Davidlohr Bueso
2016-09-21 19:46 ` [PATCH v3] " Davidlohr Bueso
2016-09-18 19:11 ` [PATCH 4/5] ipc/sem: explicitly inline check_restart Davidlohr Bueso
2016-09-18 19:11 ` [PATCH 5/5] ipc/sem: use proper list api for pending_list wakeups Davidlohr Bueso
2016-09-19 18:40 ` [PATCH -next v2 0/5] ipc/sem: semop(2) improvements Manfred Spraul
2016-09-20 15:03 ` Davidlohr Bueso
-- strict thread matches above, loose matches on Subject: below --
2016-09-12 11:53 [PATCH -next " Davidlohr Bueso
2016-09-12 11:53 ` [PATCH 2/5] ipc/sem: rework task wakeups Davidlohr Bueso
2016-09-13 18:04 ` Manfred Spraul
2016-09-14 15:45 ` Davidlohr Bueso
2016-09-18 14:37 ` Manfred Spraul
2016-09-18 18:26 ` Davidlohr Bueso
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=67e32fa9-4a51-6d05-88bf-3c38cb1a8d3e@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.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.