public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <dahi@linux.vnet.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Wanpeng Li" <kernellwp@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>, KVM <kvm@vger.kernel.org>,
	"Cornelia Huck" <cornelia.huck@de.ibm.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	"Jens Freimann" <jfrei@linux.vnet.ibm.com>
Subject: Re: [PATCH/RFC] KVM: halt_polling: provide a way to qualify wakeups during poll
Date: Tue, 3 May 2016 10:48:09 +0200	[thread overview]
Message-ID: <20160503104809.5a483f58@thinkpad-w530> (raw)
In-Reply-To: <57285A9A.2020106@de.ibm.com>

> On 05/03/2016 09:50 AM, Wanpeng Li wrote:
> > 2016-05-02 18:42 GMT+08:00 Christian Borntraeger <borntraeger@de.ibm.com>:
> > [...]  
> >> Some wakeups should not be considered a sucessful poll. For example on
> >> s390 I/O interrupts are usually floating, which means that _ALL_ CPUs
> >> would be considered runnable - letting all vCPUs poll all the time for
> >> transactional like workload, even if one vCPU would be enough.
> >> This can result in huge CPU usage for large guests.
> >> This patch lets architectures provide a way to qualify wakeups if they
> >> should be considered a good/bad wakeups in regard to polls.
> >>
> >> For s390 the implementation will fence of halt polling for anything but
> >> known good, single vCPU events. The s390 implementation for floating
> >> interrupts does a wakeup for one vCPU, but the interrupt will be delivered
> >> by whatever CPU comes first. To limit the halt polling we only mark the  
> > 
> > If the floating interrupt means that the 'CPU comes first' will
> > deliver the interrupt to all vCPUs?  
> 
> No. All CPUs do the normal vcpu_run loop. And before entering the guest
> every CPU will try to deliver pending interrupts
> 
> static int __vcpu_run(struct kvm_vcpu *vcpu)
> {
> [...]
>         do {
>                 rc = vcpu_pre_run(vcpu);   ---------------------+
>                 if (rc)						|
>                         break;					|
> [...]								|
>                 exit_reason = sie64a(vcpu->arch.sie_block,	|
>                                      vcpu->run->s.regs.gprs);	|
> [...]								|
> }								|
> 								|
> static int vcpu_pre_run(struct kvm_vcpu *vcpu)		<-------+
> {
> [...]
>         if (!kvm_is_ucontrol(vcpu->kvm)) {
>                 rc = kvm_s390_deliver_pending_interrupts(vcpu); <----
>                 if (rc)
>                         return rc;
> [...]
> }
> 
> 
> 
> and whichever comes first, will dequeue that interrupt and deliver it
> by doing the PSW swap (jumping to the interrupt handler address)
> 
> (other CPUs will then not deliver this interrupt as it is already dequeued)
> 
> 

And regarding to questions if we should exclude floating IRQs from the blocked
check: That must not be done as floating IRQ (groups) can be disabled only on
certain CPUs.

An operating system is free to setup only certain CPUs to check for interrupts
(and disable it on the others). So all VCPUs have to check for floating IRQs,
otherwise situations might be provoked where floating IRQs are pending but not
delivered to any VCPU.

David


      reply	other threads:[~2016-05-03  8:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-02 10:42 [PATCH/RFC] KVM: halt_polling: provide a way to qualify wakeups during poll Christian Borntraeger
2016-05-02 10:45 ` David Hildenbrand
2016-05-02 11:46 ` Cornelia Huck
2016-05-02 11:50   ` Christian Borntraeger
2016-05-02 13:34 ` Radim Krčmář
2016-05-02 14:30   ` Christian Borntraeger
2016-05-02 15:25     ` Radim Krčmář
2016-05-03  8:55       ` Christian Borntraeger
2016-05-02 19:44 ` David Matlack
2016-05-03  8:46   ` Christian Borntraeger
2016-05-03  5:42 ` Wanpeng Li
2016-05-03  7:00   ` Christian Borntraeger
2016-05-03  9:19     ` Cornelia Huck
2016-05-10 13:54     ` Paolo Bonzini
2016-05-03  7:50 ` Wanpeng Li
2016-05-03  8:00   ` Cornelia Huck
2016-05-03  8:00   ` Christian Borntraeger
2016-05-03  8:48     ` David Hildenbrand [this message]

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=20160503104809.5a483f58@thinkpad-w530 \
    --to=dahi@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.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