On Sun, 2013-09-15 at 10:06 +0200, Mike Galbraith wrote:
> master: Cpus 64, interleave 1 delay 0: 10039494796 in 30 secs
plus patches
master: Cpus 64, interleave 1 delay 0: 9139925137 in 30 secs
> 3.10.10: Cpus 64, interleave 1 delay 0: 129236313 in 30 secs
--
To unsubscribe from this li
On Sun, 2013-09-15 at 13:34 +0200, Manfred Spraul wrote:
> 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 mo
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, you
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 discl
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. Scala
The exclusion of complex operations in sem_lock() is insufficient:
After acquiring the per-semaphore lock, a simple op must first check that
sem_perm.lock is not locked and only after that test check complex_count.
The current code does it the other way around - and that creates a race.
Details are
6 matches
Mail list logo