Re: ipc,sem: sysv semaphore scalability

[Andrew Morton]

On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel <riel@xxxxxxxxxxx> 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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/