Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1722357 > unrolled thread

Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started  vcpus Cornelia Huck <cohuck@redhat.com> - 2017-08-29 13:30 +0200
    Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus David Hildenbrand <david@redhat.com> - 2017-08-29 14:10 +0200
      Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started  vcpus Cornelia Huck <cohuck@redhat.com> - 2017-08-29 14:50 +0200

#1722357 — Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus

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.

[toc] | [next] | [standalone]

#1722419 — Re: [PATCH RFC v3 1/9] KVM: s390: optimize detection of started vcpus

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.

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.

-- 

Thanks,

David

[toc] | [prev] | [next] | [standalone]

#1722443

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web