From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Raghavendra KT <raghavendra.kt.linux@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com,
edumazet@google.com, darren@dvhart.com, fweisbec@gmail.com,
sbw@mit.edu, torvalds@linux-foundation.org, walken@google.com,
waiman.long@hp.com, davidlohr.bueso@hp.com,
Raghavendra KT <raghavendra.kt@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC ticketlock] v3 Auto-queued ticketlock
Date: Mon, 1 Jul 2013 22:56:38 -0700 [thread overview]
Message-ID: <20130702055638.GY3773@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAC4Lta02wcg6CuYfXA3zqcUR-LoKGR4hs5KYM+1aS1Qg7A8xvg@mail.gmail.com>
On Mon, Jul 01, 2013 at 02:49:34PM +0530, Raghavendra KT wrote:
> On Sun, Jun 23, 2013 at 11:23 PM, Raghavendra KT
> <raghavendra.kt.linux@gmail.com> wrote:
> >
> >
> > On Wed, Jun 12, 2013 at 9:10 PM, Paul E. McKenney
> > <paulmck@linux.vnet.ibm.com> wrote:
> >>
> >> Breaking up locks is better than implementing high-contention locks, but
> >> if we must have high-contention locks, why not make them automatically
> >> switch between light-weight ticket locks at low contention and queued
> >> locks at high contention? After all, this would remove the need for
> >> the developer to predict which locks will be highly contended.
> >>
> >> This commit allows ticket locks to automatically switch between pure
> >> ticketlock and queued-lock operation as needed. If too many CPUs are
> >> spinning on a given ticket lock, a queue structure will be allocated
> >> and the lock will switch to queued-lock operation. When the lock becomes
> >> free, it will switch back into ticketlock operation. The low-order bit
> >> of the head counter is used to indicate that the lock is in queued mode,
> >> which forces an unconditional mismatch between the head and tail counters.
> >> This approach means that the common-case code path under conditions of
> >> low contention is very nearly that of a plain ticket lock.
> >>
> >> A fixed number of queueing structures is statically allocated in an
> >> array. The ticket-lock address is used to hash into an initial element,
> >> but if that element is already in use, it moves to the next element. If
> >> the entire array is already in use, continue to spin in ticket mode.
> >>
> >> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> [ paulmck: Eliminate duplicate code and update comments (Steven Rostedt).
> >> ]
> >> [ paulmck: Address Eric Dumazet review feedback. ]
> >> [ paulmck: Use Lai Jiangshan idea to eliminate smp_mb(). ]
> >> [ paulmck: Expand ->head_tkt from s32 to s64 (Waiman Long). ]
> >> [ paulmck: Move cpu_relax() to main spin loop (Steven Rostedt). ]
> >> [ paulmck: Reduce queue-switch contention (Waiman Long). ]
> >> [ paulmck: __TKT_SPIN_INC for __ticket_spin_trylock() (Steffen Persvold).
> >> ]
> >> [ paulmck: Type safety fixes (Steven Rostedt). ]
> >> [ paulmck: Pre-check cmpxchg() value (Waiman Long). ]
> >> [ paulmck: smp_mb() downgrade to smp_wmb() (Lai Jiangshan). ]
> >>
> > [...]
> >
> > I did test this on 32 core machine with 32 vcpu guests.
> >
> > This version gave me around 20% improvement fro sysbench and 36% improvement
> > for ebizzy, for 1x commit though other overcommited results showed
> > degradation. I have not tested Lai Jiangshan's patches on top of this yet.
> > Will report any findings.
>
> Sorry for late report.
Not a problem, thank you for running these numbers!
> With Lai's patch I see few percentage of improvement in ebizzy 1x and
> reduction in degradation in dbench 1x.
OK, good! But my guess is that even pushing the lock-acquisition
slowpath out of line, we still would not reach parity for the less-good
results. Still seems like I should add Lai Jiangshan's patches
and post them somewhere in case they are helpful in some other context.
Thanx, Paul
> But over-commit degradation seem to still persist. seeing this, I
> feel it is more of qmode overhead itself for large guests,
>
> +---+-----------+-----------+-----------+------------+-----------+
> ebizzy (rec/sec higher is better)
> +---+---+-----------+-----------+-----------+------------+-----------+
> base stdev patched stdev %improvement
> +---+-----------+-----------+-----------+------------+-----------+
> 1x 5574.9000 237.4997 7851.9000 148.6737 40.84378
> 2x 2741.5000 561.3090 1620.9000 410.8299 -40.87543
> 3x 2146.2500 216.7718 1751.8333 96.5023 -18.37702
> +---+-----------+-----------+-----------+------------+-----------+
> +---+-----------+-----------+-----------+------------+-----------+
> dbench (throughput higher is better)
> +---+-----------+-----------+-----------+------------+-----------+
> base stdev patched stdev %improvement
> +---+-----------+-----------+-----------+------------+-----------+
> 1x 14111.5600 754.4525 13826.5700 1458.0744 -2.01955
> 2x 2481.6270 71.2665 1549.3740 245.3777 -37.56620
> 3x 1510.2483 31.8634 1116.0158 26.4882 -26.10382
> +---+-----------+-----------+-----------+------------+-----------+
>
prev parent reply other threads:[~2013-07-02 5:57 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-09 19:36 [PATCH RFC ticketlock] Auto-queued ticketlock Paul E. McKenney
2013-06-10 20:47 ` Steven Rostedt
2013-06-10 20:57 ` Paul E. McKenney
2013-06-10 21:01 ` Thomas Gleixner
2013-06-10 21:15 ` Paul E. McKenney
2013-06-10 21:08 ` Steven Rostedt
2013-06-10 21:30 ` Paul E. McKenney
2013-06-10 21:35 ` Eric Dumazet
2013-06-10 21:54 ` Paul E. McKenney
2013-06-10 23:02 ` Steven Rostedt
2013-06-11 0:22 ` Paul E. McKenney
2013-06-11 0:44 ` Steven Rostedt
2013-06-11 0:51 ` Linus Torvalds
2013-06-11 7:53 ` Lai Jiangshan
2013-06-11 10:14 ` Paul E. McKenney
2013-06-11 15:22 ` Steven Rostedt
2013-06-11 16:45 ` Paul E. McKenney
2013-06-11 10:06 ` Paul E. McKenney
2013-06-11 17:53 ` Davidlohr Bueso
2013-06-11 18:05 ` Paul E. McKenney
2013-06-11 18:10 ` Steven Rostedt
2013-06-11 18:14 ` Davidlohr Bueso
2013-06-11 18:46 ` Paul E. McKenney
2013-06-12 17:50 ` Davidlohr Bueso
2013-06-12 18:15 ` Linus Torvalds
2013-06-12 20:03 ` Davidlohr Bueso
2013-06-12 20:26 ` Linus Torvalds
2013-06-12 20:40 ` Davidlohr Bueso
2013-06-12 21:06 ` Raymond Jennings
2013-06-12 23:32 ` Al Viro
2013-06-13 0:01 ` Linus Torvalds
2013-06-13 0:20 ` Al Viro
2013-06-13 0:38 ` Linus Torvalds
2013-06-13 0:49 ` Al Viro
2013-06-13 0:59 ` Linus Torvalds
2013-06-14 15:00 ` Waiman Long
2013-06-14 15:37 ` Linus Torvalds
2013-06-14 18:17 ` Waiman Long
2013-06-15 1:26 ` Benjamin Herrenschmidt
2013-06-15 3:36 ` Waiman Long
2013-06-12 20:37 ` Linus Torvalds
2013-06-12 18:18 ` Steven Rostedt
2013-06-11 9:56 ` Paul E. McKenney
2013-06-11 15:00 ` Paul E. McKenney
2013-06-11 1:04 ` Steven Rostedt
2013-06-11 9:52 ` Paul E. McKenney
2013-06-11 14:48 ` Lai Jiangshan
2013-06-11 15:10 ` Lai Jiangshan
2013-06-11 16:48 ` Paul E. McKenney
2013-06-11 17:17 ` Linus Torvalds
2013-06-11 17:30 ` Paul E. McKenney
2013-06-11 16:21 ` Paul E. McKenney
2013-06-11 15:57 ` Waiman Long
2013-06-11 16:20 ` Steven Rostedt
2013-06-11 16:43 ` Paul E. McKenney
2013-06-11 17:13 ` Steven Rostedt
2013-06-11 17:43 ` Paul E. McKenney
2013-06-11 17:35 ` Waiman Long
2013-06-11 16:36 ` Paul E. McKenney
2013-06-11 17:01 ` Steven Rostedt
2013-06-11 17:16 ` Paul E. McKenney
2013-06-11 18:41 ` Waiman Long
2013-06-11 18:54 ` Davidlohr Bueso
2013-06-11 19:49 ` Paul E. McKenney
2013-06-11 20:09 ` Steven Rostedt
2013-06-11 20:32 ` Paul E. McKenney
2013-06-11 20:53 ` Steven Rostedt
2013-06-11 20:25 ` Jason Low
2013-06-11 20:36 ` Paul E. McKenney
2013-06-11 20:56 ` Steven Rostedt
2013-06-11 21:09 ` Paul E. McKenney
2013-06-12 1:19 ` Lai Jiangshan
2013-06-12 1:58 ` Steven Rostedt
2013-06-12 10:12 ` Paul E. McKenney
2013-06-12 11:06 ` Lai Jiangshan
2013-06-12 14:21 ` Paul E. McKenney
2013-06-12 14:15 ` Lai Jiangshan
2013-06-12 14:44 ` Paul E. McKenney
2013-06-11 17:02 ` [PATCH RFC ticketlock] v2 " Paul E. McKenney
2013-06-11 17:35 ` Linus Torvalds
2013-06-11 17:49 ` Paul E. McKenney
2013-06-11 17:36 ` Steven Rostedt
2013-06-11 17:52 ` Paul E. McKenney
2013-06-12 15:40 ` [PATCH RFC ticketlock] v3 " Paul E. McKenney
2013-06-12 16:13 ` Lai Jiangshan
2013-06-12 16:59 ` Paul E. McKenney
2013-06-13 2:55 ` Lai Jiangshan
2013-06-13 15:22 ` Paul E. McKenney
2013-06-13 23:25 ` Lai Jiangshan
2013-06-13 23:57 ` Paul E. McKenney
2013-06-14 1:28 ` Lai Jiangshan
2013-06-14 23:49 ` Paul E. McKenney
2013-06-14 7:12 ` Lai Jiangshan
2013-06-14 23:46 ` Paul E. McKenney
[not found] ` <CAC4Lta3dpTDc19rXLVQkZrxbu8AJL+Foc6ocAktUAozCpk2-Mg@mail.gmail.com>
2013-07-01 9:19 ` Raghavendra KT
2013-07-02 5:56 ` Paul E. McKenney [this message]
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=20130702055638.GY3773@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=davidlohr.bueso@hp.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt.linux@gmail.com \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=waiman.long@hp.com \
--cc=walken@google.com \
/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.