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 things
On Tue, 26 Mar 2013 15:28:52 -0400 Dave Jones da...@redhat.com 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
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
>
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
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
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
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
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
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
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
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
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
torva...@linux-foundation.org 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
On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
torva...@linux-foundation.org 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
On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
torva...@linux-foundation.org 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
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
torva...@linux-foundation.org wrote:
And you never see this problem without Rik's patches?
No, never.
Could you bisect
*which* patch it starts with?
On Mon, Mar 25, 2013 at 9:01 PM, Rik van Riel r...@surriel.com wrote:
On 03/25/2013 09:47 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
And you never see this problem without Rik's patches?
No, never.
Could you bisect
On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel r...@surriel.com 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 are
On 03/25/2013 11:20 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel r...@surriel.com 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
On Mon, Mar 25, 2013 at 10:53 PM, Rik van Riel r...@surriel.com wrote:
On 03/25/2013 11:20 AM, Emmanuel Benisty wrote:
On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel r...@surriel.com wrote:
With the first four patches only, I got some X server freeze (just
tried once).
Could you try
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
semaphores.
Hi
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
On Sun, Mar 24, 2013 at 2:45 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Mar 22, 2013 at 8:19 PM, Emmanuel Benisty benist...@gmail.com 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
On Sun, Mar 24, 2013 at 6:46 AM, Emmanuel Benisty benist...@gmail.com 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
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
On Fri, Mar 22, 2013 at 8:19 PM, Emmanuel Benisty benist...@gmail.com 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
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
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
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
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
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
Hi Rik,
On Thu, Mar 21, 2013 at 2:55 AM, Rik van Riel r...@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.
I was trying your
On Fri, Mar 22, 2013 at 4:04 AM, Emmanuel Benisty benist...@gmail.com 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
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
Hi Linus,
On Fri, Mar 22, 2013 at 10:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Mar 22, 2013 at 4:04 AM, Emmanuel Benisty benist...@gmail.com wrote:
I was trying your patchset and my machine died while building a
package. I could reproduce the bug the (only) two times
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
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
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
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, 20 Mar 2013 15:55:30 -0400 Rik van Riel r...@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
On Thu, 2013-03-21 at 14:10 -0700, Andrew Morton wrote:
On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel r...@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
On Thu, 2013-03-21 at 14:10 -0700, Andrew Morton wrote:
On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel r...@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
On Thu, 21 Mar 2013 17:50:05 -0400 Peter Hurley pe...@hurleysoftware.com
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 r...@surriel.com wrote:
This series makes the sysv semaphore code more scalable,
by reducing the
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, Mar 21, 2013 at 6:12 PM, Davidlohr Bueso davidlohr.bu...@hp.com 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
On 03/21/2013 06:01 PM, Andrew Morton wrote:
On Thu, 21 Mar 2013 17:50:05 -0400 Peter Hurley pe...@hurleysoftware.com
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 r...@surriel.com wrote:
This series makes the sysv semaphore
On 03/21/2013 09:23 PM, Linus Torvalds wrote:
On Thu, Mar 21, 2013 at 6:12 PM, Davidlohr Bueso davidlohr.bu...@hp.com 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
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
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
On Wed, Mar 20, 2013 at 12:55 PM, Rik van Riel r...@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 series looks sane to me,
On Wed, Mar 20, 2013 at 1:49 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Wed, 2013-03-20 at 13:49 -0700, Linus Torvalds wrote:
On Wed, Mar 20, 2013 at 12:55 PM, Rik van Riel r...@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
101 - 158 of 158 matches
Mail list logo
