From: Manfred Spraul <manfred@colorfullife.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Nadia Derbey <Nadia.Derbey@bull.net>,
Andrew Morton <akpm@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Scalability requirements for sysv ipc (was: ipc: store ipcs into IDRs)
Date: Fri, 21 Mar 2008 10:41:47 +0100 [thread overview]
Message-ID: <47E382DB.70503@colorfullife.com> (raw)
Hi all,
I noticed that sysv ipc now uses very special locking: first a global
rw-semaphore, then within that semaphore rcu:
> linux-2.6.25-rc3:/ipc/util.c:
> struct kern_ipc_perm *ipc_lock(struct ipc_ids *ids, int id)
> {
> struct kern_ipc_perm *out;
> int lid = ipcid_to_idx(id);
>
> down_read(&ids->rw_mutex);
>
> rcu_read_lock();
> out = idr_find(&ids->ipcs_idr, lid);
ids->rw_mutex is a per-namespace (i.e.: usually global) semaphore. Thus
ipc_lock writes into a global cacheline. Everything else is based on
per-object locking, especially sysv sem doesn't contain a single global
lock/statistic counter/...
That can't be the Right Thing (tm): Either there are cases where we need
the scalability (then using IDRs is impossible), or the scalability is
never needed (then the remaining parts from RCU should be removed).
I don't have a suitable test setup, has anyone performed benchmarks
recently?
Is sysv semaphore still important, or have all apps moved to posix
semaphores/futexes?
Nadia: Do you have access to a suitable benchmark?
A microbenchmark on a single-cpu system doesn't help much (except that
2.6.25 is around factor 2 slower for sysv msg ping-pong between two
tasks compared to the numbers I remember from older kernels....)
--
Manfred
next reply other threads:[~2008-03-21 9:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 9:41 Manfred Spraul [this message]
2008-03-21 12:45 ` Scalability requirements for sysv ipc (was: ipc: store ipcs into IDRs) Nadia Derbey
2008-03-21 13:33 ` Scalability requirements for sysv ipc Manfred Spraul
2008-03-21 14:13 ` Paul E. McKenney
2008-03-21 16:08 ` Manfred Spraul
2008-03-22 5:43 ` Mike Galbraith
2008-03-22 10:10 ` Manfred Spraul
2008-03-22 11:53 ` Mike Galbraith
2008-03-22 14:22 ` Manfred Spraul
2008-03-22 19:08 ` Manfred Spraul
2008-03-25 15:50 ` Mike Galbraith
2008-03-25 16:13 ` Peter Zijlstra
2008-03-25 18:31 ` Mike Galbraith
2008-03-26 6:18 ` Mike Galbraith
2008-03-30 14:12 ` Scalability requirements for sysv ipc (+namespaces broken with SEM_UNDO) Manfred Spraul
2008-03-30 15:21 ` David Newall
2008-03-30 17:18 ` Mike Galbraith
2008-04-04 14:59 ` Nadia Derbey
2008-04-04 15:03 ` Nadia Derbey
2008-03-22 19:35 ` Scalability requirements for sysv ipc Mike Galbraith
2008-03-23 6:38 ` Manfred Spraul
2008-03-23 7:15 ` Mike Galbraith
2008-03-23 7:08 ` Mike Galbraith
2008-03-23 7:20 ` Mike Galbraith
2008-03-27 22:29 ` Bill Davidsen
2008-03-28 9:49 ` Manfred Spraul
2008-03-25 16:00 ` Nadia Derbey
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=47E382DB.70503@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=Nadia.Derbey@bull.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/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.