[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANN689GPzjJW7OiYhFJi1xLSN+606auMeJCsxR_CHL_T4aETZg@mail.gmail.com>
Date: Thu, 3 Jan 2013 02:46:01 -0800
From: Michel Lespinasse <walken@...gle.com>
To: Rik van Riel <riel@...hat.com>
Cc: linux-kernel@...r.kernel.org, aquini@...hat.com,
eric.dumazet@...il.com, lwoodman@...hat.com, jeremy@...p.org,
Jan Beulich <JBeulich@...ell.com>,
Thomas Gleixner <tglx@...utronix.de>, knoel@...hat.com
Subject: Re: [RFC PATCH 0/5] x86,smp: make ticket spinlock proportional
backoff w/ auto tuning
On Wed, Jan 2, 2013 at 9:15 PM, Rik van Riel <riel@...hat.com> wrote:
> The v2 series integrates several ideas from Michel Lespinasse
> and Eric Dumazet, which should result in better throughput and
> nicer behaviour in situations with contention on multiple locks.
>
> Please let me know if you manage to break this code in any way,
> so I can fix it...
I'm seeing some very weird things on my 3 test machines. Looks like
the spinlock delay sometimes gets crazy, at which point spinlock
performance becomes unbearable and the network driver freaks out.
# ./spinlock_load_test
1 spinlocks: 24159990
2 spinlocks: 12900657
3 spinlocks: 11547771
4 spinlocks: 9113
6 spinlocks: 259
8 spinlocks: 310
12 spinlocks: 283
16 spinlocks:
<seems to be stuck here; meanwhile my serial console fills up with
network driver cries>
Well, I take it as an incitation to pay special attention to this code review :)
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists