From: Waiman Long <waiman.long@hp.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Scott J Norton <scott.norton@hp.com>,
Douglas Hatch <doug.hatch@hp.com>
Subject: Re: [PATCH v3 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL
Date: Mon, 27 Jul 2015 13:50:59 -0400 [thread overview]
Message-ID: <55B66F83.7040105@hp.com> (raw)
In-Reply-To: <1437961615.25997.36.camel@stgolabs.net>
On 07/26/2015 09:46 PM, Davidlohr Bueso wrote:
> On Sat, 2015-07-25 at 15:31 -0700, Davidlohr Bueso wrote:
>> On Wed, 2015-07-22 at 16:12 -0400, Waiman Long wrote:
>>> The smp_store_release() is not a full barrier. In order to avoid missed
>>> wakeup, we may need to add memory barrier around locked and cpu state
>>> variables adding to complexity. As the chance of spurious wakeup is very
>>> low, it is easier and safer to just do an unconditional kick at unlock
>>> time.
>> Although I guess if SPIN_THRESHOLD is ever enlarged, the chances of
>> spurious wakeups would be greater.
>>
>>> Signed-off-by: Waiman Long<Waiman.Long@hp.com>
>> Reviewed-by: Davidlohr Bueso<dave@stgolabs.net>
> Thinking about this some more, as good practice, could you please add a
> comment in the code explicitly mentioning the spurious wakeup side
> effect? Perhaps even having something more generic for the entire kernel
> might be added/created to Documentation/spurious-wakeups.txt?
>
> Thanks,
> Davidlohr
>
The if conditional check was added with the intention to save an
unneeded PV kick when the vCPU was running. Doing an unconditional kick
doesn't do any harm other than the additional latency of the PV kick. I
will add a comment when I update the patch.
As for the spurious-wakeups.txt, I saw there are spurious wakeup
occasionally. However, I am not totally sure of the mechanism that
causes it. Also the spurious wakeup here refers to the vmenter of the
vCPU which is different from spurious wakeup of a sleeping thread. I
don't think I have enough data and information to write a document file yet.
Cheers,
Longman
next prev parent reply other threads:[~2015-07-27 17:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 20:12 [PATCH v3 0/7] locking/qspinlock: Enhance pvqspinlock performance Waiman Long
2015-07-22 20:12 ` [PATCH v3 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL Waiman Long
2015-07-25 22:31 ` Davidlohr Bueso
2015-07-27 1:46 ` Davidlohr Bueso
2015-07-27 17:50 ` Waiman Long [this message]
2015-07-27 18:41 ` Davidlohr Bueso
2015-07-31 8:39 ` Peter Zijlstra
2015-07-31 17:01 ` Waiman Long
2015-07-22 20:12 ` [PATCH v3 2/7] locking/pvqspinlock: Add pending bit support Waiman Long
2015-07-26 23:09 ` Davidlohr Bueso
2015-07-27 17:11 ` Waiman Long
2015-07-26 23:48 ` Davidlohr Bueso
2015-07-27 0:56 ` Davidlohr Bueso
2015-07-27 17:30 ` Waiman Long
2015-07-27 19:39 ` Davidlohr Bueso
2015-07-29 20:49 ` Waiman Long
2015-07-27 20:08 ` Davidlohr Bueso
2015-07-22 20:12 ` [PATCH v3 3/7] locking/pvqspinlock: Collect slowpath lock statistics Waiman Long
2015-07-27 1:14 ` Davidlohr Bueso
2015-07-27 17:33 ` Waiman Long
2015-07-22 20:12 ` [PATCH v3 4/7] locking/pvqspinlock: Enable deferment of vCPU kicking to unlock call Waiman Long
2015-07-22 20:12 ` [PATCH v3 5/7] locking/pvqspinlock: Allow vCPUs kick-ahead Waiman Long
2015-07-22 20:12 ` [PATCH v3 6/7] locking/pvqspinlock: Queue node adaptive spinning Waiman Long
2015-07-22 20:12 ` [PATCH v3 7/7] locking/pvqspinlock, x86: Optimize PV unlock code path Waiman Long
2015-07-27 1:18 ` [PATCH v3 0/7] locking/qspinlock: Enhance pvqspinlock performance Davidlohr Bueso
2015-07-27 17:36 ` Waiman Long
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=55B66F83.7040105@hp.com \
--to=waiman.long@hp.com \
--cc=dave@stgolabs.net \
--cc=doug.hatch@hp.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.