linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: cohuck@redhat.com (Cornelia Huck)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus
Date: Tue, 29 Aug 2017 14:42:47 +0200	[thread overview]
Message-ID: <20170829144247.5b0644dc.cohuck@redhat.com> (raw)
In-Reply-To: <d63ceb80-bdf7-0a24-a4ac-3265b7528a60@redhat.com>

On Tue, 29 Aug 2017 14:05:40 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 29.08.2017 13:23, Cornelia Huck wrote:
> > On Tue, 22 Aug 2017 13:31:27 +0200
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> >> On 21.08.2017 22:35, Radim Kr?m?? wrote:  
> >>> We can add a variable instead of scanning all online VCPUs to know how
> >>> many are started.  We can't trivially tell which VCPU is the last one,
> >>> though.    
> >>
> >> You could keep the started vcpus in a list. Then you might drop unsigned
> >> started_vcpus;
> >>
> >> No started vcpus: Start pointer NULL
> >> Single started vcpu: Only one element in the list (easy to check)  
> >>> 1 started vcpus: More than one element int he list (easy to check)    
> > 
> > I'm not sure the added complication of keeping a list buys us much
> > here: We only have the "look for the last vcpu not stopped" operation
> > for the 2->1 transition.
> >   
> 
> That is wrong, we also have to know the last remaining (started) VCPU.
> For that, right now we have to iterate over all VCPUs.

Yes, but that's only for the 2->1 transition... and all in all that is
still much better that before.

> 
> There shouldn't be much complexity. We already perform changes under a
> lock, so it is as simple as adding/removing from the list.
> 
> Detecting the transitions boils down to looking at two pointers.

Having a private vcpu list feels a bit wrong... and I don't really see
much benefit.

  reply	other threads:[~2017-08-29 12:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21 20:35 [PATCH RFC v3 0/9] KVM: allow dynamic kvm->vcpus array Radim Krčmář
2017-08-21 20:35 ` [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus Radim Krčmář
2017-08-22  7:26   ` Christian Borntraeger
2017-08-22 11:31   ` David Hildenbrand
2017-08-29 11:23     ` Cornelia Huck
2017-08-29 12:05       ` David Hildenbrand
2017-08-29 12:42         ` Cornelia Huck [this message]
2017-08-29 11:26   ` Cornelia Huck
2017-08-21 20:35 ` [PATCH RFC v3 2/9] KVM: arm/arm64: fix vcpu self-detection in vgic_v3_dispatch_sgi() Radim Krčmář
2017-08-22 11:43   ` David Hildenbrand
2017-08-29 10:00   ` Christoffer Dall
2017-08-21 20:35 ` [PATCH RFC v3 3/9] KVM: remember position in kvm->vcpus array Radim Krčmář
2017-08-22 11:44   ` David Hildenbrand
2017-08-29 11:30   ` Cornelia Huck
2017-08-21 20:35 ` [PATCH RFC v3 4/9] KVM: arm/arm64: use locking helpers in kvm_vgic_create() Radim Krčmář
2017-08-22 11:51   ` David Hildenbrand
2017-08-29 10:00   ` Christoffer Dall
2017-08-21 20:35 ` [PATCH RFC v3 5/9] KVM: remove unused __KVM_HAVE_ARCH_VM_ALLOC Radim Krčmář
2017-08-21 20:35 ` [PATCH RFC v3 6/9] KVM: rework kvm_vcpu_on_spin loop Radim Krčmář
2017-08-22 14:06   ` David Hildenbrand
2017-08-29 15:24     ` Cornelia Huck
2017-08-21 20:35 ` [PATCH RFC v3 7/9] KVM: add kvm_free_vcpus and kvm_arch_free_vcpus Radim Krčmář
2017-08-22 14:18   ` David Hildenbrand
2017-08-29 13:00     ` Cornelia Huck
2017-08-21 20:35 ` [PATCH RFC v3 8/9] KVM: implement kvm_for_each_vcpu with a list Radim Krčmář
2017-08-29  9:58   ` Christoffer Dall
2017-08-21 20:35 ` [PATCH RFC v3 9/9] KVM: split kvm->vcpus into chunks Radim Krčmář

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=20170829144247.5b0644dc.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).