Re: [PATCH v4 0/8] KVM paravirt remote flush tlb

[Avi Kivity <avi@redhat.com>]

On 09/04/2012 11:08 AM, Nikunj A Dadhania wrote:
> On Tue, 04 Sep 2012 10:51:06 +0300, Avi Kivity <avi@redhat.com> wrote:
>> On 09/04/2012 04:30 AM, Nikunj A Dadhania wrote:
>> > On Mon, 03 Sep 2012 17:33:46 +0300, Avi Kivity <avi@redhat.com> wrote:
>> >> On 08/21/2012 02:25 PM, Nikunj A. Dadhania wrote:
>> >> > 
>> >> > kernbench(lower is better)
>> >> > ==========================
>> >> >          base      pvflushv4      %improvement
>> >> > 1VM    48.5800       46.8513       3.55846
>> >> > 2VM   108.1823      104.6410       3.27346
>> >> > 3VM   183.2733      163.3547      10.86825
>> >> > 
>> >> > ebizzy(higher is better)
>> >> > ========================
>> >> >          base         pvflushv4      %improvement
>> >> > 1VM     2414.5000     2089.8750     -13.44481
>> >> > 2VM     2167.6250     2371.7500      9.41699
>> >> > 3VM     1600.1111     2102.5556     31.40060
>> >> > 
>> >> 
>> >> The regression is worrying.  We're improving the contended case at the
>> >> cost of the non-contended case, this is usually the wrong thing to do.
>> >> Do we have any clear idea of the cause of the regression?
>> >> 
>> > Previous perf numbers suggest that in 1VM scenario flush_tlb_others_ipi
>> > is around 2%, while for contented case its around 10%. That is what is
>> > helping contended case.
>> 
>> But what is causing the regression for the uncontended case?
>> 
> Haven't been able to nail that, any clue on how to profile would help.

perf top, perf kvm top, kvm_stat should help.


-- 
error compiling committee.c: too many arguments to function