linux-kernel - Re: [PATCH 2/5] ipc/sem: rework task wakeups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67e32fa9-4a51-6d05-88bf-3c38cb1a8d3e@colorfullife.com>
Date:   Mon, 19 Sep 2016 20:26:31 +0200
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Davidlohr Bueso <dave@...olabs.net>, akpm@...ux-foundation.org
Cc:     linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH 2/5] ipc/sem: rework task wakeups

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@...e.de>
Acked-by: Manfred Spraul <manfred@...orfullife.com>

--
     Manfred