public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Masanori Misono <m.misono760@gmail.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Rohit Jain <rohit.k.jain@oracle.com>,
	Ingo Molnar <mingo@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/1] Make vCPUs that are HLT state candidates for load balancing
Date: Wed, 26 May 2021 16:43:03 +0200	[thread overview]
Message-ID: <YK5ed8ixweIAsvlL@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210526133727.42339-1-m.misono760@gmail.com>

On Wed, May 26, 2021 at 10:37:26PM +0900, Masanori Misono wrote:
> is_vcpu_preempted() is also used in PV spinlock implementations to mitigate
> lock holder preemption problems,

It's used to abort optimistic spinners.

> etc. A vCPU holding a lock does not do HLT,

Optimistic spinning is actually part of mutexes and rwsems too, and in
those cases we might very well end up in idle while holding the lock.
However; in that case the task will have been scheduled out and the
optimistic spin loop will terminate due to that (see the ->on_cpu
condition).

> so I think this patch doesn't affect them.

That is correct.

> However, pCPU may be
> running the host's thread that has higher priority than a vCPU thread, and
> in that case, is_vcpu_preempted() should return 0 ideally.

No, in that case vcpu_is_preempted() really should return true. There is
no saying how long the vcpu is gone for.


  parent reply	other threads:[~2021-05-26 14:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 13:37 [PATCH RFC 0/1] Make vCPUs that are HLT state candidates for load balancing Masanori Misono
2021-05-26 13:37 ` [PATCH RFC 1/1] KVM: x86: Don't set preempted when vCPU does HLT VMEXIT Masanori Misono
2021-05-26 14:43 ` Peter Zijlstra [this message]
2021-05-26 14:49 ` [PATCH RFC 0/1] Make vCPUs that are HLT state candidates for load balancing Peter Zijlstra
2021-05-26 16:15   ` Sean Christopherson

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=YK5ed8ixweIAsvlL@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=dwmw@amazon.co.uk \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.misono760@gmail.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rohit.k.jain@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox