From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jiannan Ouyang <ouyang@cs.pitt.edu>
Cc: LKML <linux-kernel@vger.kernel.org>,
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>,
Rik van Riel <riel@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>
Subject: Re: Preemptable Ticket Spinlock
Date: Tue, 23 Apr 2013 07:24:44 +0530 [thread overview]
Message-ID: <5175E9E4.60903@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJocwcc0M2Xr=ozpwLRM1vejMVfofr9n-TpAXU_efB_3MaCF5Q@mail.gmail.com>
On 04/22/2013 10:12 PM, Jiannan Ouyang wrote:
> On Mon, Apr 22, 2013 at 1:58 AM, Raghavendra K T
> <raghavendra.kt@linux.vnet.ibm.com> wrote:
[...]
>>> static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
>>> {
>>> register struct __raw_tickets inc = { .tail = 1 };
>>> + unsigned int timeout = 0;
>>> + __ticket_t current_head;
>>>
>>> inc = xadd(&lock->tickets, inc);
>>> -
>>> + if (likely(inc.head == inc.tail))
>>> + goto spin;
>>> +
>>> + timeout = TIMEOUT_UNIT * (inc.tail - inc.head);
Forgot to mention about this, for immediate wait case,
you can busyloop instead of timeout (I mean
timeout = TIMEOUT_UNIT * (inc.tail - inc.head -1);
This ideas was used by Rik in his spinlock backoff patches.
>>> + do {
>>> + current_head = ACCESS_ONCE(lock->tickets.head);
>>> + if (inc.tail <= current_head) {
>>> + goto spin;
>>> + } else if (inc.head != current_head) {
>>> + inc.head = current_head;
>>> + timeout = TIMEOUT_UNIT * (inc.tail - inc.head);
>>
>>
>> Good idea indeed to base the loop on head and tail difference.. But for
>> virtualization I believe this "directly proportional notion" is little
>> tricky too.
>>
>
> Could you explain your concern a little bit more?
>
Consider a big machine with 2 VMs running.
If nth vcpu of say VM1 waiting in the queue, the question is,
Do we have to have all the n VCPU doing busyloop and thus burning
sigma (n*(n+1) * TIMEOUT_UNIT)) ?
OR
Is it that, far off vcpu in the queue worth giving his time back so that
probably some other vcpu of VM1 doing good work OR vcpu of VM2 can
benefit from this.
I mean far the vcpu in the queue, let him yield voluntarily. (inversely
proportional notion just because it is vcpu). and of course for some n <
THRESHOLD we can still have directly proportional wait idea.
Does this idea sound good ?
next prev parent reply other threads:[~2013-04-23 1:51 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 ` Preemptable Ticket Spinlock Rik van Riel
2013-04-21 23:07 ` 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 [this message]
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=5175E9E4.60903@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.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=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=riel@redhat.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 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.