All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>, Yi Sun <yi.y.sun@linux.intel.com>
Cc: Juergen Gross <jgross@suse.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
	chao.p.peng@intel.com, chao.gao@intel.com,
	isaku.yamahata@intel.com, michael.h.kelley@microsoft.com,
	tianyu.lan@microsoft.com, "K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall
Date: Wed, 31 Oct 2018 11:07:22 -0400	[thread overview]
Message-ID: <fc0bf563-b1ae-4d4b-1341-11c44b759b8a@redhat.com> (raw)
In-Reply-To: <20181031141030.GB13219@hirez.programming.kicks-ass.net>

On 10/31/2018 10:10 AM, Peter Zijlstra wrote:
> On Wed, Oct 31, 2018 at 09:54:17AM +0800, Yi Sun wrote:
>> On 18-10-23 17:33:28, Yi Sun wrote:
>>> On 18-10-23 10:51:27, Peter Zijlstra wrote:
>>>> Can you try and explain why vcpu_is_preempted() doesn't work for you?
>>> I thought HvSpinWaitInfo is used to notify hypervisor the spin number
>>> which is different with vcpu_is_preempted. So I did not consider
>>> vcpu_is_preempted.
>>>
>>> But HvSpinWaitInfo is a quite simple function and could be combined
>>> with vcpu_is_preempted together. So I think it is OK to use
>>> vcpu_is_preempted to make codes clean. I will have a try.
>> After checking codes, there is one issue to call vcpu_is_preempted.
>> There are two spin loops in qspinlock_paravirt.h. One loop in
>> 'pv_wait_node' calls vcpu_is_preempted. But another loop in
>> 'pv_wait_head_or_lock' does not call vcpu_is_preempted. It also does
>> not call any other ops of 'pv_lock_ops' in the loop. So I am afraid
>> we have to add one more ops in 'pv_lock_ops' to do this.
> Why? Would not something like the below cure that? Waiman, can you have
> a look at this; I always forget how that paravirt crud works.

There are two major reasons why the vcpu_is_preempt() test isn't done at
pv_wait_head_or_lock(). First of all, we may not have a valid prev
pointer after all if it is the first one to enter the queue while the
lock is busy. Secondly, because of lock stealing, the cpu number pointed
by a valid prev pointer may not be the actual cpu that is currently
holding the lock. Another minor reason is that we want to minimize the
lock transfer latency and so don't want to sleep too early while waiting
at the queue head.

Cheers,
Longman


  reply	other threads:[~2018-10-31 15:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19 13:13 [PATCH v1 0/2] Enable HvNotifyLongSpinWait for Hyper-V Yi Sun
2018-10-19 13:13 ` [PATCH v1 1/2] x86/hyperv: get spinlock retry number on Hyper-V Yi Sun
2018-10-19 13:13 ` [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall Yi Sun
2018-10-19 14:20   ` Juergen Gross
2018-10-22  1:53     ` Yi Sun
2018-10-22  7:32       ` Juergen Gross
2018-10-22 16:31         ` Waiman Long
2018-10-22 17:15           ` Peter Zijlstra
2018-10-22 17:27             ` Waiman Long
2018-10-22 17:31               ` Peter Zijlstra
2018-10-22 18:01                 ` Waiman Long
2018-10-23  2:57             ` Yi Sun
2018-10-23  8:51               ` Peter Zijlstra
2018-10-23  9:33                 ` Yi Sun
2018-10-31  1:54                   ` Yi Sun
2018-10-31 14:10                     ` Peter Zijlstra
2018-10-31 15:07                       ` Waiman Long [this message]
2018-10-31 17:15                         ` Peter Zijlstra
2018-11-01  3:20                           ` Yi Sun
2018-11-01  8:59                             ` Peter Zijlstra
2018-11-01 12:59                             ` Waiman Long
2018-11-05  6:54                               ` Yi Sun
2018-10-24 16:53   ` Michael Kelley
2018-10-25  2:23     ` Yi Sun
2018-10-31  2:06     ` Yi Sun

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=fc0bf563-b1ae-4d4b-1341-11c44b759b8a@redhat.com \
    --to=longman@redhat.com \
    --cc=chao.gao@intel.com \
    --cc=chao.p.peng@intel.com \
    --cc=haiyangz@microsoft.com \
    --cc=isaku.yamahata@intel.com \
    --cc=jgross@suse.com \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.h.kelley@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=tianyu.lan@microsoft.com \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=yi.y.sun@linux.intel.com \
    --subject='Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall' \
    /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

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.