From: Manfred Spraul <manfred@colorfullife.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>,
Davidlohr Bueso <davidlohr.bueso@hp.com>,
hhuang@redhat.com, Greg KH <greg@kroah.com>
Subject: Re: [PATCH 1/2] ipc/sem.c: Race in sem_lock()
Date: Sun, 15 Sep 2013 13:34:38 +0200 [thread overview]
Message-ID: <52359B4E.7060700@colorfullife.com> (raw)
In-Reply-To: <1379225343.5545.154.camel@marge.simpson.net>
Hi all,
On 09/15/2013 08:09 AM, Mike Galbraith wrote:
> On Sat, 2013-09-14 at 23:34 +0200, Manfred Spraul wrote:
>
>> The bug is probably also present in 3.10 and 3.11, but for these kernels
>> is is probably simpler just to move the test of sma->complex_count after
>> the spin_is_locked() test.
> IMHO, your 6 patch series should go to stable as well. Scalability is
> still BAD without them. Now, you've shown the lock split to be buggy.
>
> Logically, the whole thing should be reverted entirely in stable, or
> fixed up properly.
Davidlohr: Are you working on fixing the open issues?
IMHO Mike is right, especially for the 3.10 long-term kernel:
Either everything in ipc/*.c must be reverted or it should be fixed
properly (i.e.: cherry-pick ipc/*)
I have created bugzilla entries for all issues I'm aware of:
https://bugzilla.kernel.org/show_bug.cgi?id=61351
I sent a patch yesterday.
https://bugzilla.kernel.org/show_bug.cgi?id=61321
https://bugzilla.kernel.org/show_bug.cgi?id=61331
https://bugzilla.kernel.org/show_bug.cgi?id=61341
https://bugzilla.kernel.org/show_bug.cgi?id=61361
https://bugzilla.kernel.org/show_bug.cgi?id=61371
No patches for theses 5 bugs.
And: Given these numbers from Mike, I would hate to revert anything:
On 09/15/2013 10:06 AM, Mike Galbraith wrote:
> On Sun, 2013-09-15 at 08:09 +0200, Mike Galbraith wrote:
>
>> Humongous improvements...
> (a couple sem-waitzero numbers)
>
> master: Cpus 64, interleave 1 delay 0: 10039494796 in 30 secs
> 3.10.10: Cpus 64, interleave 1 delay 0: 129236313 in 30 secs
>
> (rapidly scrolling micro-font bench vs reality disclaimer)
One semop() completed every 3 ns, around 600 cpu ticks per operation.
--
Manfred
next prev parent reply other threads:[~2013-09-15 11:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-14 21:34 [PATCH 1/2] ipc/sem.c: Race in sem_lock() Manfred Spraul
2013-09-14 21:34 ` [PATCH 2/2] ipc/sem.c: optimize sem_lock() Manfred Spraul
2013-09-15 6:09 ` [PATCH 1/2] ipc/sem.c: Race in sem_lock() Mike Galbraith
2013-09-15 8:06 ` Mike Galbraith
2013-09-16 11:03 ` Mike Galbraith
2013-09-15 11:34 ` Manfred Spraul [this message]
2013-09-15 19:30 ` 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=52359B4E.7060700@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@linux-foundation.org \
--cc=davidlohr.bueso@hp.com \
--cc=efault@gmx.de \
--cc=greg@kroah.com \
--cc=hhuang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.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 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.