Roman Kagan writes:
> On Tue, Sep 25, 2018 at 11:29:57AM +0200, Paolo Bonzini wrote:
>> On 25/09/2018 10:57, Roman Kagan wrote:
>> > If we can assume that in all relevant cases vp_index coincides with the
>> > cpu index (which I think we can) then Vitaly's approach is the most
>> > efficient.
>>
Roman Kagan writes:
> On Tue, Sep 25, 2018 at 11:29:57AM +0200, Paolo Bonzini wrote:
>> On 25/09/2018 10:57, Roman Kagan wrote:
>> > If we can assume that in all relevant cases vp_index coincides with the
>> > cpu index (which I think we can) then Vitaly's approach is the most
>> > efficient.
>>
On Tue, Sep 25, 2018 at 11:29:57AM +0200, Paolo Bonzini wrote:
> On 25/09/2018 10:57, Roman Kagan wrote:
> > If we can assume that in all relevant cases vp_index coincides with the
> > cpu index (which I think we can) then Vitaly's approach is the most
> > efficient.
> >
> > If, on the opposite,
On Tue, Sep 25, 2018 at 11:29:57AM +0200, Paolo Bonzini wrote:
> On 25/09/2018 10:57, Roman Kagan wrote:
> > If we can assume that in all relevant cases vp_index coincides with the
> > cpu index (which I think we can) then Vitaly's approach is the most
> > efficient.
> >
> > If, on the opposite,
On 25/09/2018 10:57, Roman Kagan wrote:
> Speaking of the options we have, the choice depends on the assumptions
> we take. (And I guess when you spoke of quadratic complexity you
> referred to the algorithm to convert the vp_index mask into the KVM cpu
> mask.)
Right; with Vitaly's patch, if you
On 25/09/2018 10:57, Roman Kagan wrote:
> Speaking of the options we have, the choice depends on the assumptions
> we take. (And I guess when you spoke of quadratic complexity you
> referred to the algorithm to convert the vp_index mask into the KVM cpu
> mask.)
Right; with Vitaly's patch, if you
On Mon, Sep 24, 2018 at 06:55:28PM +0200, Paolo Bonzini wrote:
> On 24/09/2018 18:24, Paolo Bonzini wrote:
> > Hi Paolo,
> >
> > could you please clarify what needs to be done to get this merged? In
> > particular, are you OK with my comment above or do we need to do
> > something with it (e.g.
On Mon, Sep 24, 2018 at 06:55:28PM +0200, Paolo Bonzini wrote:
> On 24/09/2018 18:24, Paolo Bonzini wrote:
> > Hi Paolo,
> >
> > could you please clarify what needs to be done to get this merged? In
> > particular, are you OK with my comment above or do we need to do
> > something with it (e.g.
On 24/09/2018 18:24, Paolo Bonzini wrote:
> Hi Paolo,
>
> could you please clarify what needs to be done to get this merged? In
> particular, are you OK with my comment above or do we need to do
> something with it (e.g. get back to the 'logarythmic search' from v2)?
>
> In kvm/queue I can see
On 24/09/2018 18:24, Paolo Bonzini wrote:
> Hi Paolo,
>
> could you please clarify what needs to be done to get this merged? In
> particular, are you OK with my comment above or do we need to do
> something with it (e.g. get back to the 'logarythmic search' from v2)?
>
> In kvm/queue I can see
Vitaly Kuznetsov writes:
> Paolo Bonzini writes:
>
>> On 22/08/2018 12:18, Vitaly Kuznetsov wrote:
>>> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
>>> use it instead of traversing full vCPU list every time.
>>
>> ... but if it doesn't, the algorithm is now quadratic,
Vitaly Kuznetsov writes:
> Paolo Bonzini writes:
>
>> On 22/08/2018 12:18, Vitaly Kuznetsov wrote:
>>> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
>>> use it instead of traversing full vCPU list every time.
>>
>> ... but if it doesn't, the algorithm is now quadratic,
Paolo Bonzini writes:
> On 22/08/2018 12:18, Vitaly Kuznetsov wrote:
>> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
>> use it instead of traversing full vCPU list every time.
>
> ... but if it doesn't, the algorithm is now quadratic, isn't i?
Yes,
I even had an
Paolo Bonzini writes:
> On 22/08/2018 12:18, Vitaly Kuznetsov wrote:
>> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
>> use it instead of traversing full vCPU list every time.
>
> ... but if it doesn't, the algorithm is now quadratic, isn't i?
Yes,
I even had an
On 22/08/2018 12:18, Vitaly Kuznetsov wrote:
> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
> use it instead of traversing full vCPU list every time.
... but if it doesn't, the algorithm is now quadratic, isn't i?
Paolo
On 22/08/2018 12:18, Vitaly Kuznetsov wrote:
> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
> use it instead of traversing full vCPU list every time.
... but if it doesn't, the algorithm is now quadratic, isn't i?
Paolo
VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
use it instead of traversing full vCPU list every time.
To support the change split off get_vcpu_idx_by_vpidx() from
get_vcpu_by_vpidx().
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Roman Kagan
---
arch/x86/kvm/hyperv.c
VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
use it instead of traversing full vCPU list every time.
To support the change split off get_vcpu_idx_by_vpidx() from
get_vcpu_by_vpidx().
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Roman Kagan
---
arch/x86/kvm/hyperv.c
18 matches
Mail list logo
