From: Davidlohr Bueso <dave@stgolabs.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: manfred@colorfullife.com,
Linux Containers <containers@lists.linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
khlebnikov@yandex-team.ru, prakash.sangappa@oracle.com,
luto@kernel.org, akpm@linux-foundation.org, oleg@redhat.com,
serge.hallyn@ubuntu.com, esyr@redhat.com, jannh@google.com,
linux-security-module@vger.kernel.org,
Pavel Emelyanov <xemul@openvz.org>,
Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
Subject: Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces
Date: Fri, 30 Mar 2018 13:45:57 -0700 [thread overview]
Message-ID: <20180330204557.5cgyipyqawfte3ml@linux-n805> (raw)
In-Reply-To: <87y3i91fxh.fsf@xmission.com>
On Fri, 30 Mar 2018, Eric W. Biederman wrote:
>Davidlohr Bueso <dave@stgolabs.net> writes:
>
>> I ran this on a 40-core (no ht) Westmere with two benchmarks. The first
>> is Manfred's sysvsem lockunlock[1] program which uses _processes_ to,
>> well, lock and unlock the semaphore. The options are a little
>> unconventional, to keep the "critical region small" and the lock+unlock
>> frequency high I added busy_in=busy_out=10. Similarly, to get the
>> worst case scenario and have everyone update the same semaphore, a single
>> one is used. Here are the results (pretty low stddev from run to run)
>> for doing 100,000 lock+unlock.
>>
>> - 1 proc:
>> * vanilla
>> total execution time: 0.110638 seconds for 100000 loops
>> * dirty
>> total execution time: 0.120144 seconds for 100000 loops
>>
>> - 2 proc:
>> * vanilla
>> total execution time: 0.379756 seconds for 100000 loops
>> * dirty
>> total execution time: 0.477778 seconds for 100000 loops
>>
>> - 4 proc:
>> * vanilla
>> total execution time: 6.749710 seconds for 100000 loops
>> * dirty
>> total execution time: 4.651872 seconds for 100000 loops
>>
>> - 8 proc:
>> * vanilla
>> total execution time: 5.558404 seconds for 100000 loops
>> * dirty
>> total execution time: 7.143329 seconds for 100000 loops
>>
>> - 16 proc:
>> * vanilla
>> total execution time: 9.016398 seconds for 100000 loops
>> * dirty
>> total execution time: 9.412055 seconds for 100000 loops
>>
>> - 32 proc:
>> * vanilla
>> total execution time: 9.694451 seconds for 100000 loops
>> * dirty
>> total execution time: 9.990451 seconds for 100000 loops
>>
>> - 64 proc:
>> * vanilla
>> total execution time: 9.844984 seconds for 100032 loops
>> * dirty
>> total execution time: 10.016464 seconds for 100032 loops
>>
>> Lower task counts show pretty massive performance hits of ~9%, ~25%
>> and ~30% for single, two and four/eight processes. As more are added
>> I guess the overhead tends to disappear as for one you have a lot
>> more locking contention going on.
>
>Can you check your notes on the 4 process case? As I read the 4 process
>case above it is ~30% improvement. Either that is a typo or there is the
>potential for quite a bit of noise in the test case.
Yeah, sorry that was a typo. Unlike the second benchmark I didn't have
this one automated but it's always the vanilla kernel that outperforms
the dirty.
Thanks,
Davidlohr
next prev parent reply other threads:[~2018-03-30 20:58 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 17:18 [RESEND RFC] translate_pid API nagarathnam.muthusamy
2018-03-13 20:47 ` Jann Horn
2018-03-13 21:20 ` Nagarathnam Muthusamy
2018-03-13 21:28 ` Jann Horn
2018-03-13 21:44 ` Nagarathnam Muthusamy
2018-03-13 22:00 ` Jann Horn
2018-03-13 22:45 ` Nagarathnam Muthusamy
2018-03-13 23:10 ` Jann Horn
2018-03-13 23:52 ` Nagarathnam Muthusamy
2018-03-14 3:29 ` Eric W. Biederman
2018-03-14 21:22 ` Nagarathnam Muthusamy
2018-03-14 22:03 ` Eric W. Biederman
2018-03-20 20:14 ` Nagarathnam Muthusamy
2018-03-21 0:33 ` Eric W. Biederman
2018-03-23 19:11 ` [REVIEW][PATCH 00/11] ipc: Fixing the pid namespace support Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 01/11] sem/security: Pass kern_ipc_perm not sem_array into the sem security hooks Eric W. Biederman
2018-03-23 21:46 ` Casey Schaufler
2018-03-28 23:20 ` Davidlohr Bueso
2018-03-23 19:16 ` [REVIEW][PATCH 02/11] shm/security: Pass kern_ipc_perm not shmid_kernel into the shm " Eric W. Biederman
2018-03-23 21:54 ` Casey Schaufler
2018-03-23 19:16 ` [REVIEW][PATCH 03/11] msg/security: Pass kern_ipc_perm not msg_queue into the msg_queue " Eric W. Biederman
2018-03-23 21:55 ` Casey Schaufler
2018-03-24 5:37 ` Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 04/11] sem: Move struct sem and struct sem_array into ipc/sem.c Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 05/11] shm: Move struct shmid_kernel into ipc/shm.c Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 06/11] msg: Move struct msg_queue into ipc/msg.c Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 07/11] ipc: Move IPCMNI from include/ipc.h into ipc/util.h Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 08/11] ipc/util: Helpers for making the sysvipc operations pid namespace aware Eric W. Biederman
2018-03-23 19:16 ` [REVIEW][PATCH 09/11] ipc/shm: Fix shmctl(..., IPC_STAT, ...) between pid namespaces Eric W. Biederman
2018-03-23 21:17 ` NAGARATHNAM MUTHUSAMY
2018-03-23 21:33 ` Eric W. Biederman
2018-03-23 21:41 ` NAGARATHNAM MUTHUSAMY
2018-03-28 23:04 ` Eric W. Biederman
2018-03-28 23:18 ` Nagarathnam Muthusamy
2018-03-23 19:16 ` [REVIEW][PATCH 10/11] ipc/msg: Fix msgctl(..., " Eric W. Biederman
2018-03-23 21:21 ` NAGARATHNAM MUTHUSAMY
2018-03-23 19:16 ` [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, " Eric W. Biederman
2018-03-29 0:52 ` Davidlohr Bueso
2018-03-30 19:09 ` Davidlohr Bueso
2018-03-30 20:12 ` Eric W. Biederman
2018-03-30 20:45 ` Davidlohr Bueso [this message]
2018-04-02 11:11 ` Manfred Spraul
2018-03-24 5:40 ` [REVIEW][PATCH 12/11] ipc: Directly call the security hook in ipc_ops.associate Eric W. Biederman
2018-03-28 23:40 ` Davidlohr Bueso
2018-03-31 2:13 ` James Morris
2018-03-24 5:42 ` [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks Eric W. Biederman
2018-03-25 0:05 ` Casey Schaufler
2018-03-28 23:38 ` Davidlohr Bueso
2018-03-28 23:57 ` Davidlohr Bueso
2018-03-29 1:12 ` [REVIEW][PATCH 00/11] ipc: Fixing the pid namespace support Davidlohr Bueso
2018-03-29 18:42 ` Eric W. Biederman
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=20180330204557.5cgyipyqawfte3ml@linux-n805 \
--to=dave@stgolabs.net \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=esyr@redhat.com \
--cc=jannh@google.com \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=manfred@colorfullife.com \
--cc=nagarathnam.muthusamy@oracle.com \
--cc=oleg@redhat.com \
--cc=prakash.sangappa@oracle.com \
--cc=serge.hallyn@ubuntu.com \
--cc=xemul@openvz.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;
as well as URLs for NNTP newsgroup(s).