From: Andrew Morton <akpm@linux-foundation.org>
To: Rik van Riel <riel@surriel.com>
Cc: torvalds@linux-foundation.org, davidlohr.bueso@hp.com,
linux-kernel@vger.kernel.org, hhuang@redhat.com,
jason.low2@hp.com, walken@google.com, lwoodman@redhat.com,
chegu_vinod@hp.com, Peter Hurley <peter@hurleysoftware.com>,
Dave Jones <davej@redhat.com>
Subject: Re: ipc,sem: sysv semaphore scalability
Date: Thu, 21 Mar 2013 14:10:58 -0700 [thread overview]
Message-ID: <20130321141058.76e028e492f98f6ee6e60353@linux-foundation.org> (raw)
In-Reply-To: <1363809337-29718-1-git-send-email-riel@surriel.com>
On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel <riel@surriel.com> wrote:
> This series makes the sysv semaphore code more scalable,
> by reducing the time the semaphore lock is held, and making
> the locking more scalable for semaphore arrays with multiple
> semaphores.
>
> The first four patches were written by Davidlohr Buesso, and
> reduce the hold time of the semaphore lock.
>
> The last three patches change the sysv semaphore code locking
> to be more fine grained, providing a performance boost when
> multiple semaphores in a semaphore array are being manipulated
> simultaneously.
These patches conflict pretty badly with Peter's:
ipc-clamp-with-min.patch
ipc-separate-msg-allocation-from-userspace-copy.patch
ipc-tighten-msg-copy-loops.patch
ipc-set-efault-as-default-error-in-load_msg.patch
ipc-remove-msg-handling-from-queue-scan.patch
ipc-implement-msg_copy-as-a-new-receive-mode.patch
ipc-simplify-msg-list-search.patch
ipc-refactor-msg-list-search-into-separate-function.patch
ipc-refactor-msg-list-search-into-separate-function-fix.patch
(they're at http://ozlabs.org/~akpm/mmots/broken-out/)
We're in a bit of a mess at present.
Last month Peter sent a ten-patch series which fixed an oops (Subject:
"ipc MSG_COPY fixes"). The series did other stuff, so we merged into
mainline just two bugfix patches. Then davej hit a trinity oops
(Subject: "ipc/testmsg GPF.") and testing confirmed that the remaining
eight patches in Peter's series fixed that up. Nobody has yet
identified which of the eight does the good deed. So we need to
either:
a) revert the original two fixes "ipc: fix potential oops when src
msg > 4k w/ MSG_COPY" and "ipc: don't allocate a copy larger than
max" or
b) try reverting "ipc: don't allocate a copy larger than max", as
"ipc: fix potential oops when src msg > 4k w/ MSG_COPY" looks pretty
harmless or
c) work out which of the remaining 8 fixes the new oops and merge that or
d) merge all 8 fixes or
e) something else.
Whichever way we go, we should get a wiggle on - this has been hanging
around for too long. Dave, do you have time to determine whether
reverting 88b9e456b1649722673ff ("ipc: don't allocate a copy larger
than max") fixes things up?
next prev parent reply other threads:[~2013-03-21 21:11 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 19:55 Rik van Riel
2013-03-20 19:55 ` [PATCH 1/7] ipc: remove bogus lock comment for ipc_checkid Rik van Riel
2013-03-20 19:55 ` [PATCH 2/7] ipc: introduce obtaining a lockless ipc object Rik van Riel
2013-03-20 19:55 ` [PATCH 3/7] ipc: introduce lockless pre_down ipcctl Rik van Riel
2013-03-20 19:55 ` [PATCH 4/7] ipc,sem: do not hold ipc lock more than necessary Rik van Riel
2013-03-20 19:55 ` [PATCH 5/7] ipc,sem: open code and rename sem_lock Rik van Riel
2013-03-22 1:14 ` Davidlohr Bueso
2013-03-20 19:55 ` [PATCH 6/7] ipc,sem: have only one list in struct sem_queue Rik van Riel
2013-03-22 1:14 ` Davidlohr Bueso
2013-03-20 19:55 ` [PATCH 7/7] ipc,sem: fine grained locking for semtimedop Rik van Riel
2013-03-22 1:14 ` Davidlohr Bueso
2013-03-22 23:01 ` Michel Lespinasse
2013-03-22 23:38 ` Rik van Riel
2013-03-22 23:42 ` [PATCH 7/7 part3] fix for sem_lock Rik van Riel
2013-03-20 20:49 ` ipc,sem: sysv semaphore scalability Linus Torvalds
2013-03-20 20:56 ` Linus Torvalds
2013-03-20 20:57 ` Davidlohr Bueso
2013-03-21 21:10 ` Andrew Morton [this message]
2013-03-21 21:47 ` Peter Hurley
2013-03-21 21:50 ` Peter Hurley
2013-03-21 22:01 ` Andrew Morton
2013-03-22 3:38 ` Rik van Riel
2013-03-26 19:28 ` Dave Jones
2013-03-26 19:43 ` Andrew Morton
2013-03-29 16:17 ` Dave Jones
2013-03-29 18:00 ` Linus Torvalds
2013-03-29 18:04 ` Dave Jones
2013-03-29 18:10 ` Linus Torvalds
2013-03-29 18:43 ` Linus Torvalds
2013-03-29 19:06 ` Dave Jones
2013-03-29 19:13 ` Linus Torvalds
2013-03-29 19:26 ` Linus Torvalds
2013-03-29 19:36 ` Peter Hurley
2013-04-02 16:08 ` Sasha Levin
2013-04-02 17:24 ` Linus Torvalds
2013-04-02 17:52 ` Linus Torvalds
2013-04-02 19:53 ` Sasha Levin
2013-04-02 20:00 ` Dave Jones
2013-03-29 19:33 ` Peter Hurley
2013-03-29 19:54 ` Linus Torvalds
2013-04-01 7:40 ` Stanislav Kinsbursky
2013-03-29 20:41 ` Linus Torvalds
2013-03-29 21:12 ` Linus Torvalds
2013-03-29 23:16 ` Linus Torvalds
2013-03-30 1:36 ` Emmanuel Benisty
2013-03-30 2:08 ` Davidlohr Bueso
2013-03-30 3:02 ` Emmanuel Benisty
2013-03-30 3:46 ` Linus Torvalds
2013-03-30 4:33 ` Emmanuel Benisty
2013-03-30 5:10 ` Linus Torvalds
2013-03-30 5:57 ` Emmanuel Benisty
2013-03-30 17:22 ` Linus Torvalds
2013-03-31 2:38 ` Emmanuel Benisty
2013-03-31 5:01 ` Davidlohr Bueso
2013-03-31 13:45 ` Rik van Riel
2013-03-31 17:10 ` Linus Torvalds
2013-03-31 17:02 ` Emmanuel Benisty
2013-03-30 2:09 ` Linus Torvalds
2013-03-30 2:55 ` Davidlohr Bueso
2013-03-29 19:01 ` Dave Jones
2013-05-03 15:03 ` Peter Hurley
2013-03-22 1:12 ` Davidlohr Bueso
2013-03-22 1:23 ` Linus Torvalds
2013-03-22 3:40 ` Rik van Riel
2013-03-22 7:30 ` Mike Galbraith
2013-03-22 11:04 ` Emmanuel Benisty
2013-03-22 15:37 ` Linus Torvalds
2013-03-23 3:19 ` Emmanuel Benisty
2013-03-23 19:45 ` Linus Torvalds
2013-03-24 13:46 ` Emmanuel Benisty
2013-03-24 17:10 ` Linus Torvalds
2013-03-25 13:47 ` Emmanuel Benisty
2013-03-25 14:00 ` Rik van Riel
2013-03-25 14:03 ` Rik van Riel
2013-03-25 15:20 ` Emmanuel Benisty
2013-03-25 15:53 ` Rik van Riel
2013-03-25 17:09 ` Emmanuel Benisty
2013-03-25 14:01 ` Rik van Riel
2013-03-25 14:21 ` Emmanuel Benisty
2013-03-26 17:59 ` Davidlohr Bueso
2013-03-26 18:14 ` Rik van Riel
2013-03-26 18:35 ` Andrew Morton
2013-04-16 23:30 ` Andrew Morton
2013-05-04 15:55 ` Jörn Engel
2013-05-04 18:12 ` Borislav Petkov
2013-05-06 14:47 ` Jörn Engel
2013-03-22 17:51 ` Davidlohr Bueso
2013-03-25 20:21 ` Sasha Levin
2013-03-25 20:38 ` [PATCH -mm -next] ipc,sem: fix lockdep false positive Rik van Riel
2013-03-25 21:42 ` Michel Lespinasse
2013-03-25 21:51 ` Michel Lespinasse
2013-03-25 21:56 ` Sasha Levin
2013-03-25 21:52 ` Sasha Levin
2013-03-26 13:19 ` Peter Zijlstra
2013-03-26 13:40 ` Michel Lespinasse
2013-03-26 14:27 ` Peter Zijlstra
2013-03-26 15:19 ` Rik van Riel
2013-03-27 8:40 ` Peter Zijlstra
2013-03-27 8:42 ` Peter Zijlstra
2013-03-27 11:22 ` Michel Lespinasse
2013-03-27 12:02 ` Peter Zijlstra
2013-03-27 20:00 ` Rik van Riel
2013-03-28 20:23 ` [PATCH v2 " Rik van Riel
2013-03-29 2:50 ` Michel Lespinasse
2013-03-29 9:57 ` Peter Zijlstra
2013-03-29 13:21 ` Michel Lespinasse
2013-03-29 12:07 ` Rik van Riel
2013-03-29 13:08 ` Michel Lespinasse
2013-03-29 13:24 ` Rik van Riel
2013-03-29 13:55 ` [PATCH v3 " Rik van Riel
2013-03-29 13:59 ` Michel Lespinasse
2013-03-26 14:25 ` [PATCH " Rik van Riel
2013-03-26 17:33 ` ipc,sem: sysv semaphore scalability Sasha Levin
2013-03-26 17:51 ` Davidlohr Bueso
2013-03-26 18:07 ` Sasha Levin
2013-03-26 18:17 ` Rik van Riel
2013-03-26 20:00 ` [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo Rik van Riel
2013-04-05 4:38 ` Mike Galbraith
2013-04-05 13:21 ` Rik van Riel
2013-04-05 16:26 ` Mike Galbraith
2013-04-16 12:37 ` Mike Galbraith
2013-03-26 17:55 ` ipc,sem: sysv semaphore scalability Paul E. McKenney
2013-03-28 15:32 ` [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo Rik van Riel
2013-03-28 21:05 ` Davidlohr Bueso
2013-03-29 1:00 ` Michel Lespinasse
2013-03-29 1:14 ` Sasha Levin
2013-03-30 13:35 ` Sasha Levin
2013-03-31 1:30 ` Rik van Riel
2013-03-31 4:09 ` 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=20130321141058.76e028e492f98f6ee6e60353@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=chegu_vinod@hp.com \
--cc=davej@redhat.com \
--cc=davidlohr.bueso@hp.com \
--cc=hhuang@redhat.com \
--cc=jason.low2@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=peter@hurleysoftware.com \
--cc=riel@surriel.com \
--cc=torvalds@linux-foundation.org \
--cc=walken@google.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 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®