On Sat, 4 May 2013 20:12:45 +0200, Borislav Petkov wrote:
> On Sat, May 04, 2013 at 11:55:58AM -0400, Jörn Engel wrote:
> > Blockconsole currently lives here:
> > https://git.kernel.org/cgit/linux/kernel/git/joern/bcon2.git/
>
> Tja, if only that were upstream...
Linus has a pull request. If he
On Sat, May 04, 2013 at 11:55:58AM -0400, Jörn Engel wrote:
> Blockconsole currently lives here:
> https://git.kernel.org/cgit/linux/kernel/git/joern/bcon2.git/
Tja, if only that were upstream...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsu
On Sat, 23 March 2013 10:19:16 +0700, Emmanuel Benisty wrote:
>
> I could reproduce it but could you please let me know what would be
> the right tools I should use to catch the original oops?
> This is what I got but I doubt it will be helpful:
> http://i.imgur.com/Mewi1hC.jpg
You could use eith
On 03/29/2013 03:01 PM, Dave Jones wrote:
On Tue, Mar 26, 2013 at 12:43:09PM -0700, Andrew Morton wrote:
> On Tue, 26 Mar 2013 15:28:52 -0400 Dave Jones wrote:
>
> > On Thu, Mar 21, 2013 at 02:10:58PM -0700, Andrew Morton wrote:
> >
> > > Whichever way we go, we should get a wiggle on
On Tue, 26 Mar 2013 11:35:33 -0700 Andrew Morton
wrote:
> Do we need the locking at all? What does it actually do?
>
> sem_lock_and_putref(sma);
> if (sma->sem_perm.deleted) {
> sem_unlock(sma, -1);
>
On Tue, Apr 02, 2013 at 03:53:01PM -0400, Sasha Levin wrote:
> On 04/02/2013 01:52 PM, Linus Torvalds wrote:
> > On Tue, Apr 2, 2013 at 9:08 AM, Sasha Levin wrote:
> >>
> >> By just playing with the 'msgsz' parameter with MSG_COPY set.
> >
> > Hmm. Looking closer, I suspect you're testing w
On 04/02/2013 01:52 PM, Linus Torvalds wrote:
> On Tue, Apr 2, 2013 at 9:08 AM, Sasha Levin wrote:
>>
>> By just playing with the 'msgsz' parameter with MSG_COPY set.
>
> Hmm. Looking closer, I suspect you're testing without commit
> 88b9e456b164 ("ipc: don't allocate a copy larger than max"). Th
On Tue, Apr 2, 2013 at 9:08 AM, Sasha Levin wrote:
>
> By just playing with the 'msgsz' parameter with MSG_COPY set.
Hmm. Looking closer, I suspect you're testing without commit
88b9e456b164 ("ipc: don't allocate a copy larger than max"). That
should limit the size passed in to prepare_copy -> lo
On Tue, Apr 2, 2013 at 9:08 AM, Sasha Levin wrote:
>
> If you guys are already looking at this, the conversions between size_t,
> long and int in the do_msgrcv/load_msg/alloc_msg code are a mess. You could
> trigger anything from:
Good catch.
Let's just change the "(long)bufsz < 0" into "bufsz >
On 03/29/2013 03:36 PM, Peter Hurley wrote:
> On Fri, 2013-03-29 at 12:26 -0700, Linus Torvalds wrote:
>> On Fri, Mar 29, 2013 at 12:06 PM, Dave Jones wrote:
>>>
>>> Here's an oops I just hit..
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 000f
>>> IP: [] testmsg.isr
29.03.2013 22:43, Linus Torvalds пишет:
On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
>
>Now that I have that reverted, I'm not seeing msgrcv traces any more, but
>I've started seeing this..
>
>general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Do you have CONFIG_CHECKPOINT_R
On Sun, Mar 31, 2013 at 6:45 AM, Rik van Riel wrote:
>
> Should we use "semid" here, like Linus suggested, instead of "un->semid"?
As Davidlohr noted, in linux-next the rcu read-lock is held over the
whole thing, so no, un->semid should be stable once "un" has been
re-looked-up under the semaphor
Hi Davidlohr,
On Sun, Mar 31, 2013 at 12:01 PM, Davidlohr Bueso
wrote:
> Specially dropping the rcu read lock before the continue statement
> (sorry for not mentioning this in the last email).
I was missing this indeed, thanks. Still the same issues however...
I'll do some more testing on the sa
On 03/31/2013 01:01 AM, Davidlohr Bueso wrote:
diff --git a/ipc/sem.c b/ipc/sem.c
index f257afe..74cedfe 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1867,8 +1867,7 @@ void exit_sem(struct task_struct *tsk)
struct sem_array *sma;
struct sem_undo *un;
On Sat, 2013-03-30 at 11:33 +0700, Emmanuel Benisty wrote:
> On Sat, Mar 30, 2013 at 10:46 AM, Linus Torvalds
> wrote:
> > On Fri, Mar 29, 2013 at 8:02 PM, Emmanuel Benisty
> > wrote:
> >>
> >> Then I start building a random package and the problems start. They
> >> may also happen without compi
Hi Linus,
On Sun, Mar 31, 2013 at 12:22 AM, Linus Torvalds
wrote:
> On Fri, Mar 29, 2013 at 10:57 PM, Emmanuel Benisty
> wrote:
>> On Sat, Mar 30, 2013 at 12:10 PM, Linus Torvalds
>>>
>>> This came from the gcc build?
>>
>> yes, very early in the build process, IIRC this line was repeated a
>>
On Fri, Mar 29, 2013 at 10:57 PM, Emmanuel Benisty wrote:
> On Sat, Mar 30, 2013 at 12:10 PM, Linus Torvalds
>>
>> This came from the gcc build?
>
> yes, very early in the build process, IIRC this line was repeated a
> few times and the build just stalled.
Ok, we're bringing out the crazy hacks n
On Sat, Mar 30, 2013 at 12:10 PM, Linus Torvalds
wrote:
>> Another shot in
>> the dark, I had this weird message when trying to build gcc:
>> semop(2): encountered an error: Identifier removed
>
> This came from the gcc build?
yes, very early in the build process, IIRC this line was repeated a
fe
On Fri, Mar 29, 2013 at 9:33 PM, Emmanuel Benisty wrote:
>
> I just tried the 7 original patches + the 2 one liners from -next +
> modified Linus' patch (attached)
.. that patch looks fine.
> on the top of 3.9-rc4 using
> PREEMPT_NONE and after moving sem_lock(sma, NULL, -1) as explained
> above
On Sat, Mar 30, 2013 at 10:46 AM, Linus Torvalds
wrote:
> On Fri, Mar 29, 2013 at 8:02 PM, Emmanuel Benisty wrote:
>>
>> Then I start building a random package and the problems start. They
>> may also happen without compiling but this seems to trigger the bug
>> quite quickly.
>
> I suspect it's
On Fri, Mar 29, 2013 at 8:02 PM, Emmanuel Benisty wrote:
>
> Then I start building a random package and the problems start. They
> may also happen without compiling but this seems to trigger the bug
> quite quickly.
I suspect it's about preemption, and the build just results in enough
scheduling
Hi Davidlohr,
On Sat, Mar 30, 2013 at 9:08 AM, Davidlohr Bueso wrote:
> Not sure which one liner you refer to, but, if you haven't already done
> so, please try with these fixes (queued in linux-next):
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=a9cead0347283f3e
On Fri, 2013-03-29 at 19:09 -0700, Linus Torvalds wrote:
> On Fri, Mar 29, 2013 at 6:36 PM, Emmanuel Benisty wrote:
> >
> > I had to slightly modify the patch since it wouldn't match the changes
> > introduced by 7-7-ipc-sem-fine-grained-locking-for-semtimedop.patch,
> > hope that was the right th
On Fri, Mar 29, 2013 at 6:36 PM, Emmanuel Benisty wrote:
>
> I had to slightly modify the patch since it wouldn't match the changes
> introduced by 7-7-ipc-sem-fine-grained-locking-for-semtimedop.patch,
> hope that was the right thing to do. So, what I tried was: original 7
> patches + the one lin
On Sat, 2013-03-30 at 08:36 +0700, Emmanuel Benisty wrote:
> Hi Linus,
>
> On Sat, Mar 30, 2013 at 6:16 AM, Linus Torvalds
> wrote:
> > Emmanuel, can you try the attached patch? I think it applies cleanly
> > on top of the scalability series too without any changes, but I didn't
> > check if the
Hi Linus,
On Sat, Mar 30, 2013 at 6:16 AM, Linus Torvalds
wrote:
> Emmanuel, can you try the attached patch? I think it applies cleanly
> on top of the scalability series too without any changes, but I didn't
> check if the patches perhaps changed some of the naming or something.
I had to slight
On Fri, Mar 29, 2013 at 2:12 PM, Linus Torvalds
wrote:
>
> I dunno. I'm still not sure this is triggerable, but it looks bad. But
> both the semaphore case and the msg cases seem to be solvable by
> moving the unlock down, and shm seem to have no getref/putref users to
> race with, so this (whites
On Fri, Mar 29, 2013 at 1:41 PM, Linus Torvalds
wrote:
>
> The alternative would be to make sure the thing is always locked (and
> in a rcu-read-safe region) before putref/getref. The only place (apart
> from the initial allocation, which doesn't matter, because nothing can
> see if itf that path
On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
>
> Now that I have that reverted, I'm not seeing msgrcv traces any more, but
> I've started seeing this..
>
> general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> RIP: 0010:[] [] free_msg+0x2b/0x40
> Call Trace:
> [] freeque+0xcf/0
On Fri, Mar 29, 2013 at 12:33 PM, Peter Hurley wrote:
> On Fri, 2013-03-29 at 11:43 -0700, Linus Torvalds wrote:
>> I think I foud at least one bug in the MSG_COPY stuff: it leaks the
>> "copy" allocation if
>>
>> mode == SEARCH_LESSEQUAL
>>
>> but maybe I'm misreading it.
>
> Yes, you're misr
On Fri, 2013-03-29 at 12:26 -0700, Linus Torvalds wrote:
> On Fri, Mar 29, 2013 at 12:06 PM, Dave Jones wrote:
> >
> > Here's an oops I just hit..
> >
> > BUG: unable to handle kernel NULL pointer dereference at 000f
> > IP: [] testmsg.isra.5+0x1a/0x60
>
> Btw, looking at the code lea
On Fri, 2013-03-29 at 11:43 -0700, Linus Torvalds wrote:
> I think I foud at least one bug in the MSG_COPY stuff: it leaks the
> "copy" allocation if
>
> mode == SEARCH_LESSEQUAL
>
> but maybe I'm misreading it.
Yes, you're misreading it. copy_msg() returns the 'copy' address when
copying is
On Fri, Mar 29, 2013 at 12:06 PM, Dave Jones wrote:
>
> Here's an oops I just hit..
>
> BUG: unable to handle kernel NULL pointer dereference at 000f
> IP: [] testmsg.isra.5+0x1a/0x60
Btw, looking at the code leading up to this, what the f*ck is wrong
with the IPC stuff?
It's using t
On Fri, Mar 29, 2013 at 12:06 PM, Dave Jones wrote:
>
> Btw, something that's really bothering me is just how much bogus
> 'follow-on' spew we have lately. I'm not sure what changed, but it
> seems to have gotten worse.
.. we have many more sanity checks, and they tend to trigger in the
case of u
On Fri, Mar 29, 2013 at 11:43:25AM -0700, Linus Torvalds wrote:
> On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
> >
> > Now that I have that reverted, I'm not seeing msgrcv traces any more, but
> > I've started seeing this..
> >
> > general protection fault: [#1] PREEMPT SMP DEBUG_
On Tue, Mar 26, 2013 at 12:43:09PM -0700, Andrew Morton wrote:
> On Tue, 26 Mar 2013 15:28:52 -0400 Dave Jones wrote:
>
> > On Thu, Mar 21, 2013 at 02:10:58PM -0700, Andrew Morton wrote:
> >
> > > Whichever way we go, we should get a wiggle on - this has been hanging
> > > around for too
On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
>
> Now that I have that reverted, I'm not seeing msgrcv traces any more, but
> I've started seeing this..
>
> general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Do you have CONFIG_CHECKPOINT_RESTORE enabled? Does it go away if you
d
On Fri, Mar 29, 2013 at 11:04 AM, Dave Jones wrote:
>
> mainline. Your current tree.
Ok, that's what I thought you were generally testing, just wanted to
verify. The subject kind of implied otherwise..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, Mar 29, 2013 at 11:00:27AM -0700, Linus Torvalds wrote:
> On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
> >
> > Now that I have that reverted, I'm not seeing msgrcv traces any more, but
> > I've started seeing this..
> >
> > general protection fault: [#1] PREEMPT SMP DEBUG_
On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
>
> Now that I have that reverted, I'm not seeing msgrcv traces any more, but
> I've started seeing this..
>
> general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
>
> Looks like seg was already kfree'd.
Just to clarify: is this you te
On Tue, Mar 26, 2013 at 12:43:09PM -0700, Andrew Morton wrote:
> On Tue, 26 Mar 2013 15:28:52 -0400 Dave Jones wrote:
>
> > On Thu, Mar 21, 2013 at 02:10:58PM -0700, Andrew Morton wrote:
> >
> > > Whichever way we go, we should get a wiggle on - this has been hanging
> > > around for too
On Tue, 26 Mar 2013 15:28:52 -0400 Dave Jones wrote:
> On Thu, Mar 21, 2013 at 02:10:58PM -0700, Andrew Morton wrote:
>
> > 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 88b9e456b16497
On Thu, Mar 21, 2013 at 02:10:58PM -0700, Andrew Morton wrote:
> 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 t
On Tue, 26 Mar 2013 10:59:27 -0700 Davidlohr Bueso
wrote:
> On Mon, 2013-03-25 at 20:47 +0700, Emmanuel Benisty wrote:
> > On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
> > wrote:
> > > And you never see this problem without Rik's patches?
> >
> > No, never.
> >
> > > Could you bisect
> >
On 03/26/2013 02:07 PM, Sasha Levin wrote:
On 03/26/2013 01:51 PM, Davidlohr Bueso wrote:
On Tue, 2013-03-26 at 13:33 -0400, Sasha Levin wrote:
On 03/20/2013 03:55 PM, Rik van Riel wrote:
This series makes the sysv semaphore code more scalable,
by reducing the time the semaphore lock is held,
On 03/26/2013 01:59 PM, Davidlohr Bueso wrote:
From: Davidlohr Bueso
Subject: [PATCH] ipc, sem: prevent possible deadlock
In semctl_main(), when cmd == GETALL, we're locking
sma->sem_perm.lock (through sem_lock_and_putref), yet
after the conditional, we lock it again.
Unlock sma right after ex
On 03/20/2013 03:55 PM, Rik van Riel 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.
Hi Rik,
Another issue that came up is:
[ 96.347341]
On 03/26/2013 01:51 PM, Davidlohr Bueso wrote:
> On Tue, 2013-03-26 at 13:33 -0400, Sasha Levin wrote:
>> On 03/20/2013 03:55 PM, Rik van Riel wrote:
>>> This series makes the sysv semaphore code more scalable,
>>> by reducing the time the semaphore lock is held, and making
>>> the locking more sca
On Mon, 2013-03-25 at 20:47 +0700, Emmanuel Benisty wrote:
> On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
> wrote:
> > And you never see this problem without Rik's patches?
>
> No, never.
>
> > Could you bisect
> > *which* patch it starts with? Are the first four ones ok (the moving
> > of t
On Tue, Mar 26, 2013 at 01:33:07PM -0400, Sasha Levin wrote:
> On 03/20/2013 03:55 PM, Rik van Riel 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
>
On Tue, 2013-03-26 at 13:33 -0400, Sasha Levin wrote:
> On 03/20/2013 03:55 PM, Rik van Riel 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
> > semap
On 03/20/2013 03:55 PM, Rik van Riel wrote:
> Include lkml in the CC: this time... *sigh*
> ---8<---
>
> 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
> semaphore
On Mon, Mar 25, 2013 at 10:53 PM, Rik van Riel wrote:
> On 03/25/2013 11:20 AM, Emmanuel Benisty wrote:
>>
>> On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel wrote:
>
> With the first four patches only, I got some X server freeze (just
> tried once).
Could you try bo
On 03/25/2013 11:20 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel wrote:
With the first four patches only, I got some X server freeze (just
tried once).
Could you try booting with panic=1 so the kernel panics on the first
oops?
Sorry that should be "oops=panic"
On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel wrote:
>>> With the first four patches only, I got some X server freeze (just
>>> tried once).
>>
>>
>> Could you try booting with panic=1 so the kernel panics on the first
>> oops?
>
>
> Sorry that should be "oops=panic"
>
>
>> Maybe that way (if we a
On Mon, Mar 25, 2013 at 9:01 PM, Rik van Riel wrote:
> On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
>>
>> On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
>> wrote:
>>>
>>> And you never see this problem without Rik's patches?
>>
>>
>> No, never.
>>
>>> Could you bisect
>>> *which* patch it st
On 03/25/2013 10:00 AM, Rik van Riel wrote:
On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
wrote:
And you never see this problem without Rik's patches?
No, never.
Could you bisect
*which* patch it starts with? Are the first four ones ok (th
On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
wrote:
And you never see this problem without Rik's patches?
No, never.
Could you bisect
*which* patch it starts with? Are the first four ones ok (the moving
of the locking around, but without t
On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
wrote:
And you never see this problem without Rik's patches?
No, never.
Could you bisect
*which* patch it starts with? Are the first four ones ok (the moving
of the locking around, but without t
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
wrote:
> And you never see this problem without Rik's patches?
No, never.
> Could you bisect
> *which* patch it starts with? Are the first four ones ok (the moving
> of the locking around, but without the fine-grained ones), for
> example?
With t
On Sun, Mar 24, 2013 at 6:46 AM, Emmanuel Benisty wrote:
>
> Thanks Linus. I hope I got this right, here's the result (3.9-rc4, 7+1
> patches): http://i.imgur.com/BebGZxV.jpg
Ok, that's *slightly* more informative, but not much. At least now we
see the actual page fault information, and see what
On Sun, Mar 24, 2013 at 2:45 AM, Linus Torvalds
wrote:
> On Fri, Mar 22, 2013 at 8:19 PM, Emmanuel Benisty wrote:
>>
>> I could reproduce it but could you please let me know what would be
>> the right tools I should use to catch the original oops?
>> This is what I got but I doubt it will be help
On Fri, Mar 22, 2013 at 8:19 PM, Emmanuel Benisty wrote:
>
> I could reproduce it but could you please let me know what would be
> the right tools I should use to catch the original oops?
> This is what I got but I doubt it will be helpful:
> http://i.imgur.com/Mewi1hC.jpg
In this case, I think t
Hi Linus,
On Fri, Mar 22, 2013 at 10:37 PM, Linus Torvalds
wrote:
> On Fri, Mar 22, 2013 at 4:04 AM, Emmanuel Benisty wrote:
>>
>> I was trying your patchset and my machine died while building a
>> package. I could reproduce the bug the (only) two times I tried.
>> There's a poor quality picture
On Wed, 2013-03-20 at 15:55 -0400, Rik van Riel wrote:
> Include lkml in the CC: this time... *sigh*
> ---8<---
>
> 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
On Fri, Mar 22, 2013 at 4:04 AM, Emmanuel Benisty wrote:
>
> I was trying your patchset and my machine died while building a
> package. I could reproduce the bug the (only) two times I tried.
> There's a poor quality picture here: http://i.imgur.com/MuYuyQC.jpg
Hmm. The original oops may well hav
Hi Rik,
On Thu, Mar 21, 2013 at 2:55 AM, Rik van Riel 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.
I was trying your patchset and my mac
On Wed, 2013-03-20 at 15:55 -0400, Rik van Riel wrote:
> Include lkml in the CC: this time... *sigh*
> ---8<---
>
> 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
On 03/21/2013 09:23 PM, Linus Torvalds wrote:
On Thu, Mar 21, 2013 at 6:12 PM, Davidlohr Bueso wrote:
ipc lock contention:
100 users: 8,74% (vanilla)3.17% (v3 patchset)
400 users: 21,86% (vanilla)5.23% (v3 patchset)
800 users 84,35% (vanilla)7.39% (v3 patchset)
Ok, I'd call
On 03/21/2013 06:01 PM, Andrew Morton wrote:
On Thu, 21 Mar 2013 17:50:05 -0400 Peter Hurley
wrote:
On Thu, 2013-03-21 at 14:10 -0700, Andrew Morton wrote:
On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel wrote:
This series makes the sysv semaphore code more scalable,
by reducing the time
On Thu, Mar 21, 2013 at 6:12 PM, Davidlohr Bueso wrote:
>
> ipc lock contention:
> 100 users: 8,74% (vanilla)3.17% (v3 patchset)
> 400 users: 21,86% (vanilla)5.23% (v3 patchset)
> 800 users 84,35% (vanilla)7.39% (v3 patchset)
Ok, I'd call that pretty much "solved". Sure, it's sti
On Wed, 2013-03-20 at 15:55 -0400, Rik van Riel wrote:
> Include lkml in the CC: this time... *sigh*
> ---8<---
>
> 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
On Thu, 21 Mar 2013 17:50:05 -0400 Peter Hurley
wrote:
> On Thu, 2013-03-21 at 14:10 -0700, Andrew Morton wrote:
> > On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel wrote:
> >
> > > This series makes the sysv semaphore code more scalable,
> > > by reducing the time the semaphore lock is held,
On Thu, 2013-03-21 at 14:10 -0700, Andrew Morton wrote:
> On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel 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 m
On Thu, 2013-03-21 at 14:10 -0700, Andrew Morton wrote:
> On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel 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 m
On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel 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
On Wed, 2013-03-20 at 13:49 -0700, Linus Torvalds wrote:
> On Wed, Mar 20, 2013 at 12:55 PM, Rik van Riel 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
On Wed, Mar 20, 2013 at 1:49 PM, Linus Torvalds
wrote:
>
> It *would* be lovely to see this run with the actual Swingbench
> numbers. The microbenchmark always looked much nicer. Do the
> additional multi-semaphore scalability patches on top of Davidlohr's
> patches help with the swingbench issue,
On Wed, Mar 20, 2013 at 12:55 PM, Rik van Riel 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 series looks sane to me, and I like how
Include lkml in the CC: this time... *sigh*
---8<---
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 Buess
80 matches
Mail list logo
