From: Halil Pasic <pasic@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Michael Mueller <mimu@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
Matthew Rosato <mjrosato@linux.ibm.com>,
David Hildenbrand <david@redhat.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Tony Krowiak <akrowiak@linux.ibm.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
farman@linux.ibm.com, kvm@vger.kernel.org,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [PATCH 1/3] KVM: s390: clear kicked_mask before sleeping again
Date: Wed, 20 Oct 2021 10:14:50 +0200 [thread overview]
Message-ID: <20211020101450.1edbbc1f.pasic@linux.ibm.com> (raw)
In-Reply-To: <20211020080816.69d26708@p-imbrenda>
On Wed, 20 Oct 2021 08:08:16 +0200
Claudio Imbrenda <imbrenda@linux.ibm.com> wrote:
> > >> + clear_bit(vcpu->vcpu_idx, vcpu->kvm->arch.gisa_int.kicked_mask);
> > >
> > > so, you unconditionally clear the flag, before knowing if the vCPU is
> > > runnable?
Right. I talked about this with Mimu. It would extend the section
guarded by the bit, and than may be a good thing. Maybe we should
measure that alternative as well.
> > >
> > > from your description I would have expected to only clear the bit if
> > > the vCPU is not runnable.
> > >
> > > would things break if we were to try to kick the vCPU again after
> > > clearing the bit, but before dispatching it?
> >
> > The whole logic is just an optimization to avoid unnecessary wakeups.
> > When the bit is set a wakup might be omitted.
> > I prefer to do an unneeded wakeup over not doing a wakeup so I think
> > over-clearing is safer.
> > In fact, getting rid of this micro-optimization would be a valid
> > alternative.
>
> my only concern was if things would break in case we kick the vCPU
> again after clearing the bit; it seems nothing breaks, so I'm ok with it
I'm not sure about the exact impact of over-waking.
kvm_s390_vcpu_wakeup() sets vcpu->valid_wakeup which is I believe used
for some halt poll heuristics. We unset that in
kvm_arch_vcpu_block_finish(). If we cleared only conditionally the
protection would extend for that as well. Which would be a good thing.
The statistics stuff in kvm_vcpu_wake_up() does account for already
running, so I see no correctness issues there.
Regards,
Halil
next prev parent reply other threads:[~2021-10-20 8:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 17:53 [PATCH 0/3] fixes for __airqs_kick_single_vcpu() Halil Pasic
2021-10-19 17:53 ` [PATCH 1/3] KVM: s390: clear kicked_mask before sleeping again Halil Pasic
2021-10-19 21:22 ` Christian Borntraeger
2021-10-20 5:35 ` Claudio Imbrenda
2021-10-20 6:03 ` Christian Borntraeger
2021-10-20 6:08 ` Claudio Imbrenda
2021-10-20 8:14 ` Halil Pasic [this message]
2021-10-20 10:42 ` Claudio Imbrenda
2021-10-20 8:06 ` Michael Mueller
2021-10-20 10:44 ` Claudio Imbrenda
2021-10-19 17:54 ` [PATCH 2/3] KVM: s390: preserve deliverable_mask in __airqs_kick_single_vcpu Halil Pasic
2021-10-19 21:24 ` Christian Borntraeger
2021-10-20 5:39 ` Claudio Imbrenda
2021-10-20 8:08 ` Michael Mueller
2021-10-19 17:54 ` [PATCH 3/3] KVM: s390: clear kicked_mask if not idle after set Halil Pasic
2021-10-19 21:35 ` Christian Borntraeger
2021-10-20 5:14 ` Christian Borntraeger
2021-10-20 7:52 ` Halil Pasic
2021-10-26 8:52 ` Christian Borntraeger
2021-10-20 9:48 ` Michael Mueller
2021-10-20 10:31 ` Christian Borntraeger
2021-10-20 10:45 ` Halil Pasic
2021-10-20 10:52 ` Christian Borntraeger
2021-10-20 10:51 ` Michael Mueller
2021-10-20 11:04 ` [PATCH 0/3] fixes for __airqs_kick_single_vcpu() Christian Borntraeger
2021-10-20 12:12 ` Halil Pasic
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=20211020101450.1edbbc1f.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=schnelle@linux.ibm.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 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.