From: Rik van Riel <riel@redhat.com>
To: Jiannan Ouyang <ouyang@cs.pitt.edu>
Cc: LKML <linux-kernel@vger.kernel.org>,
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Avi Kivity <avi.kivity@gmail.com>, Gleb Natapov <gleb@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Srikar <srikar@linux.vnet.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
KVM <kvm@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Chegu Vinod <chegu_vinod@hp.com>,
"Andrew M. Theurer" <habanero@linux.vnet.ibm.com>,
Srivatsa Vaddagiri <srivatsa.vaddagiri@gmail.com>,
Andrew Jones <drjones@redhat.com>, Gleb Natapov <gleb@redhat.com>,
Karen Noel <knoel@redhat.com>
Subject: Re: Preemptable Ticket Spinlock
Date: Sun, 21 Apr 2013 17:12:48 -0400 [thread overview]
Message-ID: <51745650.9050204@redhat.com> (raw)
In-Reply-To: <CAJocwccu5QQyuKRvgNyPSFz2K_rzCW419W9-XdSUYOL7+KqQKg@mail.gmail.com>
On 04/20/2013 06:12 PM, Jiannan Ouyang wrote:
> Hello Everyone,
>
> I recently came up with a spinlock algorithm that can adapt to
> preemption, which you may be interested in. The intuition is to
> downgrade a fair lock to an unfair lock automatically upon preemption,
> and preserve the fairness otherwise. It is a guest side optimization,
> and can be used as a complementary technique to host side optimizations
> like co-scheduling and Pause-Loop Exiting.
>
> In my experiments, it improves VM performance by 5:32X on average, when
> running on a non paravirtual VMM, and by 7:91X when running on a VMM
> that supports a paravirtual locking interface (using a pv preemptable
> ticket spinlock), when executing a set of microbenchmarks as well as a
> realistic e-commerce benchmark.
>
> A detailed algorithm description can be found in my VEE 2013 paper,
> Preemptable Ticket Spinlocks: Improving Consolidated Performance in the
> Cloud
> Jiannan Ouyang, John R. Lange
> ouyang,jacklange@cs.pitt.edu <mailto:jacklange@cs.pitt.edu>
> University of Pittsburgh
> http://people.cs.pitt.edu/~ouyang/files/publication/preemptable_lock-ouyang-vee13.pdf
Your algorithm is very clever, and very promising.
However, it does increase the size of the struct spinlock, and adds
an additional atomic operation to spin_unlock, neither of which I
suspect are necessary.
If we always incremented the ticket number by 2 (instead of 1), then
we could use the lower bit of the ticket number as the spinlock.
If we do NOT run virtualized, we simply increment the ticket by 2
in spin_unlock, and the code can remain otherwise the same.
If we do run virtualized, we take that spinlock after acquiring
the ticket (or timing out), just like in your code. In the
virtualized spin_unlock, we can then release the spinlock and
increment the ticket in one operation: by simply increasing the
ticket by 1.
In other words, we should be able to keep the overhead of this
to an absolute minimum, and keep spin_unlock to be always the
same cost it is today.
--
All rights reversed
next parent reply other threads:[~2013-04-21 21:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJocwccu5QQyuKRvgNyPSFz2K_rzCW419W9-XdSUYOL7+KqQKg@mail.gmail.com>
2013-04-21 21:12 ` Rik van Riel [this message]
2013-04-21 23:07 ` Preemptable Ticket Spinlock Jiannan Ouyang
2013-04-22 5:59 ` Raghavendra K T
2013-04-22 11:51 ` Peter Zijlstra
2013-04-22 12:52 ` Rik van Riel
2013-04-22 19:49 ` Peter Zijlstra
2013-04-22 19:56 ` Rik van Riel
2013-04-22 20:05 ` Jiannan Ouyang
2013-04-22 20:08 ` Peter Zijlstra
2013-04-22 20:32 ` Rik van Riel
2013-04-22 20:44 ` Peter Zijlstra
2013-04-22 20:48 ` Peter Zijlstra
2013-04-22 20:50 ` Rik van Riel
2013-04-22 20:50 ` Jiannan Ouyang
2013-04-22 20:54 ` Chegu Vinod
2013-04-22 20:46 ` Jiannan Ouyang
2013-04-22 20:49 ` Rik van Riel
2013-04-22 21:01 ` Peter Zijlstra
2013-04-23 5:03 ` Raghavendra K T
2013-04-22 20:55 ` Peter Zijlstra
2013-04-22 21:31 ` Jiannan Ouyang
2013-04-22 23:08 ` Rik van Riel
2013-04-23 5:57 ` Gleb Natapov
2013-04-23 1:42 ` Raghavendra K T
2013-05-30 11:56 ` Raghavendra K T
2013-05-30 20:14 ` Thomas Gleixner
2013-04-22 21:56 ` Andi Kleen
2013-04-22 23:13 ` Rik van Riel
2013-04-22 5:58 ` Raghavendra K T
2013-04-22 16:42 ` Jiannan Ouyang
2013-04-23 1:54 ` Raghavendra K T
2013-04-26 20:10 ` Andrew Theurer
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=51745650.9050204@redhat.com \
--to=riel@redhat.com \
--cc=avi.kivity@gmail.com \
--cc=chegu_vinod@hp.com \
--cc=drjones@redhat.com \
--cc=gleb@redhat.com \
--cc=habanero@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=knoel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=ouyang@cs.pitt.edu \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=srivatsa.vaddagiri@gmail.com \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox